Atoms (Work In Progress)

As an effort to reflect the "Node" system of Drupal, I am working on a system of "Atoms" and "Bonds".

The Atom table itself is sufficient for basic page content; it contains an atom_id field and a version key, allowing for archiving of changed data.

Most of the time you will want to extend the atom by linking it to another domain model. This model should have an atomic_id field to allow the atom to select the proper record; also, the given table should have only one record that matches a given ID.

Alternately you can create a domain class that satisfies the Model_ZupalatomIF class and acts as a decorator for the Atomic record. So, whether the Model_Zupalatoms class satisfies the interface or acts as a resource for another class with the same ability, there exists in the data system a class that satisfies the interface and can provide the basic fields it defines.

The utility of the atom system is that it allows references between any two domains that satisfy the atomic interface. This bond can be the classic child/parent relationship but is not limited to a heirarchy; for instance a two way "friends" bond could exist between any number of users, creating arbitrary networks. Similarly, there is no reason to enforce the one parent per record rule that typifies most strict heirarchies.

Bonds

Bonds are managed with the Bond table records.

The bond creates both the atomic_id of the from and to records and the name of the model class, which can be either the Model_Zupalatoms class or another class that satisfies the atomic interface. It is the foundation of elaborate networks which are the purpose of Atoms in the first place. Note that the bond system is best used when its indeterminate nature is desired; that is, if you know by the nature of the relationship that you will always be joining to a specific table then the bond will only add overhead to your relationships.

However when you want to create relationships between a diverse set of data, for instance a collection of media assets from diffferent tables, you can't beat the bond system.

Also, bonds can be trinary; the optional bond_atom field can join a qualifying atom to the bond; for instance if you wanted to note that image X was added to album Y by user Z, the bond_atom field can be handy to annote the user. Even more complex annotations can be created by using a custom atomic interface class that contains a host of metadata about the join; you could create a Contribution class that includes the user, a datestamp, an IP or whatever and use that as the bond_atom, using the default body for a contributor note.

Open ended networks can be fairly expensive for a high volume site; a caching system, whether JSON or Memcache, is recommended for sites with substantial networks.

Ions

Ions allow you to add arbitrary properties (name/value data) to an atom. Apologies to the science communities: Ions are atoms with an irregular number of electrons, so properties might better be reflected as electrons, so in a literal model, properties might be better compared to the electrons themselves; however the result of adding an Ion to a record is comparable to a "charged" atom: a record that has a little extra, whether as a taxonomy, a field that is too sparse to justify an extra field in a table, etc.

Ions are of course less efficient than regular fields but they do allow a simple mechanism to, for instance, create an arraylike field structure. Unlike Atoms, they are not the basis for a complex network of information -- they are "leaf" nodes.