Skip to content
Borislav Iordanov edited this page Oct 22, 2015 · 1 revision

= Events = Atoms in a HyperGraphDB are in general static entities. They don't induce behavior by themselves. Behavior is generated by means of events. While HyperGraphDB has an event framework, it is targetted purely to data management. Scriba behavioral events operate on a higher level. The events framework is defined in the subpackage scriba.events. The framework consists of the following elements:

  • Events are arbitrary objects (not necessarily persisted as HGDB atoms).
  • Event types are also aribtrary objects, but they are persisted as atoms and have HGDB handles.
  • Events are handled by objects implementing the EventHandler interface.
  • The source and target of an event are called the publisher and the subscriber respectively. An event subscription is a HGDB link with 3 ordered atoms: the event type, the publisher and the subscriber. The run-time instance of a subscriber atom must implement the EventHandler interface. The link type is the EventPubSub class.
  • Events are triggered by calling the EventDispatcher.dispatch method. This method will find all subscribers for a particular (event type, publisher) combination and call their 'handle' method to "take care" of the event.

That's about it. To publish an event, you have the originating atom's handle, the event type handle and a run-time event object (possibly null). To make an event handler atom subscribe for an atom, create an EventPubSub link and add it to the niche HyperGraphDB.

= Cells =

The Mathematica notebook UI concept is generalized a bit as follows:

  • Cells are visual containers of single atoms. In turn, they are always contained in a CellGroup. Cell contain their value as an HGAtomRef. In general, the mode of the atom reference is 'floating' (so that an atom will be eventually deleted if not used), but it's up to the code that creates the cell to decide.
  • A CellGroup is a named container of cells. It can itself be nested in another (parent) CellGroup.
  • Both cells and cell groups have a set of attribute in the form of a name->value map.
  • Both cells and cell groups are stored as HGDB atoms themselves.
  • Parent-child relationships between cells and cell groups is directly represented by the CellGroup as a linking its members.

In a scripting notebook, instead of having an input/output cell distinction, we have that input cells are cells which contain an atom of type 'Scriptlet'. And output cells are cells that contain the result of the evaluation of a scriptlet (the result is also stored as an atom). When an input cell is evaluated, the result is stored in an output cell by triggering an event of type EvalResultEventType where the event itself is simply the result of the evaluation.

So in a sense, a cell is a visual placeholder and a behavioral component for arbitrary atoms. Dependending on the type of atom they hold, they will offer a different visual display/editing capabilities. One way to implement this is to have a set of component factories that produce visuals (e.g. JComponent) from atom types. Thus when the atom type is a JComponent itself, the factory will simply return the value as its own visual. When the atom type is a java.util.List, some JComponent/JTable that display the list in an intelligent could be returned, etc. The same goes for CellGroups: each cell group can have an associated visual depending on how it is tagged. A notebook view for a cellgroup is one possibility. But the full piccolo-based desktop can also be seen as a viewer of a CellGroup where each member of the cell group has a coordinate location and possibly some other attributes.

Clone this wiki locally