Two of the key points of DRAGOS are configurability and extensibility. We have invested a lot of time and thought to make the system as flexible as possible. As a result, there are a number of different points where extensions can plug in, and there is usually more than one way to implement a given requirement. This document is aimed at people who want to write their own extensions - its study is not required for people who simply want to use any of the available extensions.
The Guide to Wrappers deals in detail with the Wrapper mechanism, one of the most popular ways to implement an extension.
Many extensions will have to keep internal data, e.g. formulas for dynamically calculating attribute values. Two mechanisms are supported by DRAGOS, using MetaAttributes and storing as graph data. An extension could also implement its own storage through database or file access, but this is not recommended: It reduces portability and network transparency, and can not be combined with other extensions like versioning.
This method is especially recommended when you have to store complex data, and most easily implemented if you already wrap GraphPool/Schema and/or use GraphPool's Wrapper mechanism.
You should take a look at the FilteringGraphPool and
FilteringSchema classes in the core GM. They allow you to store
your internal data in the same data source the application uses,
but hide it from any caller unless you explicitely deactivate filtering.
Another option would be to store your data in a separate GraphPool,
but that might be more difficult to set up.
Since manipulating your internal data will result in DataEvents, you
should also hide them, otherwise you will probably confuse the application.
The EventManager offers a facility for this purpose, see
EventManager.addPreFilter(EventFilter) for details.
A hint on using this feature: Tag all your internal data with a
MetaAttribute flag upon creation. Then write an EventFilter that
rejects events if the source of the event has that MetaAttribute.
If you need to store references to the public graph data, there are two possibilities: Using Edges/Relations or using IDs. The former would require changing the Schema definition to allow these connections, keeping the edges updated whenever the target is modified to prevent consistency exceptions because of dangling edges, and carefully hiding all these changes and additional data. While basically possible, it is much easier to use IDs stored in Attributes of your internal data to maintain such links.
This mechanism is pretty self-explanatory: You can store any type of additional information with a GraphEntity, GraphEntityClass or Attribute. Just take care that you use unique meta-attribute keys. Prefixing them with the java package name should work fine. In contrast to the case above, references to the actual graph data will almost exclusively be stored in the form of IDs.
