Use-Cases and other stories

Core

Devilstick provides an utility to add new or modify existing models and compositions (which are a different kind of model on top of a main-model). In first instance a model defines a whole data-cage. In second instance there are compositions of data across different data-cages.

Plone specific preconditions

Devilstick is built to be used outside CMF/Plone. To use it in Plone the following is given:

In Plone a "type" consists of two mandatory cages (plone settings and dcmetadata) and one type specific cage. A composition glues them together and enables a form to edit data from different cages at once. The Plone specific type uses one Devilstick-enabled base-class to hook into CMF and its needs. A Factory-Type-Information (FTI) need to be provided for each type. In Plone we already have GenericSetup loading the FTI. Aditionally we have a setup-handler for GenericSetup to import and export the models from XML.

Stories

Considering a developer going the path of manual type writing, he starts writing a python-egg containing a GenericSetup-profile with all situps need to be done. Then he adds an FTI and creates the model in the profile. After importing the profile th type is available in Plone.

Considering a developer using a tool like ArchGenXML to generate types defined in UML. He draw his diagram, generate a python egg and after installing and enabling its profile the type is available in Plone.

Considering an integrator who like to add one or more fields to an existent type. Using portal_setup he exports the current devilstick model as an tarball. On his maschine he extracts it and edit the model and probably a composition. After packaging the changes back into an tarball he imports it and has the type immedialty changed. If he did his work he might give the developer the tarball to build a python-module from it.

Considering a site-administrator which like to create or change types/ forms TTW (the TTW-Editor is an application on top of Devilstick and not scope of its core). He goes to the control-panel, clicks on the types icon, selects one type or creates a new one and gets a form- and view-editor. In here he adds by drag'n'drop form-elements to create new and re-use existing fields and arrange them on the screen. After pressing save the new model can be exported using GenericSetup and handled as usal (see above).

Core and Plone

In Devilstick there a usally two options to add behaviour to types: subscribers and adapters.

Devilstick notifies its environment by zope-events about what happens, like add, modify, delete. Notifications are done on the internal representations (cages, molecules, atoms) and in the case of Plone also on the Devilstick-enabled type.

In the model its possible to mark cages, molecules and atoms with interfaces. Those interfaces must already exist in code.

Out of scope of the devilstick core, but part of its Plone integration is the possibility to also mark the Devilstick enabled object at runtime with an marker-interface.

Having those interfaces allows to adapt these objects or to subscribe to their events.

Stories

Considering a developer did write its type manually. After adding an interfaces.py to his code with the marker interface, he'll add``<implements>path.to.interfaces.IFancyBehaviour</implements>`` to either cage, molecule or atom sections of the model. After marking it this way he can react on the events.

Considering an integrator who like to add behaviour to an existent type. As written above he exports the type as tarball, adds the implements tags to the sections where he need behaviour by re-using existent interfaces describing the desired behaviour. After importing his changes he is able to re-act on the events with tools such as content-rules.

Considering a site-administrator which like to add behaviour to existing or his own types. He'll fire up the TTW-Editor (an application on top of Devilstick and not scope of its core) and selects from dropdown what behaviour is wanted. This provides that a set of behaviours was registered before by developers.