[Grok-dev] Grok/Zope Technologies for State Machine

[Laurence Rowe]

Take a look at repoze.workflow: 
http://repoze.org/viewcvs/repoze.workflow/trunk/docs/

Laurence

PAW wrote:
> Hi,
> 
> Over the last 6 months I've been researching and thinking about implementing
> a (semi) distributed state-machine framework (in my spare time). The
> investigation has led me to the decision to base the whole thing on
> Zope/Grok. This is because I envisage the ZODB playing a central part in the
> application, and it seems somehow natural to publish objects using Zope.
> Furthermore, the component-based aspect appears to be a natural fit for a
> 'state' based system, whereby states are just special components providing a
> certain interface. After looking at Grok and Zope, and all the functionality
> available, I feel my head is about to explode.  So I'm writing in the hope
> that someone could provide a little guidance on how to progress. I have
> developed a confidence and allegience with grok however, because a like how
> Martijn Faassen speaks about framework design, and martian configuration
> fits my head so much better than using some separate configuration language,
> etc... 
> 
> Firstly, the architecture in brief. The way I see it, developers will write
> states classes that provide an interface IState that I've actually written
> as:
> 
> # A loose description of what it is to implement 'state-ness'
> class IState(IDrawable):
>     """
>     A state interface contains the necessary components
>     to be instantiated with a dictionary parameter and
>     have the method 'action' be called on it to proceed.
> 
>     action : Must return an object from the symbols attribute
>     symbol : Contains the full list of all possible results
>              from this state. This can be used by the runtime
>              for interface checking purposes, but more
>              importantly, can be used by a graphical editor
>              to draw the object with its transitions in place.
>              A static verifier may also use this attribute to
>              check whether transitions have been described for
>              all possible return symbols.
>     """
>     symbols = interface.Attribute(""" The list of symbols that the """ \
>                                   """ state can generate. """)
> 
>     def __call__(params=None):
>         """ Create a state object with the given hashable. """
> 
>     def action():
>         """ Perform some action during the state's life. """
> 
> At configuration time, the system will find all classes that the developer
> has implemented that provides IState, creates an object from them using
> __new__, and stores them at some well known location in the object database.
> (Is it possible to do this at runtime, perhaps using pynotify to check when
> the directory changes?)
> 
> A developer will also write a transition table, but this will be written in
> a graphical way using the same sort of system as Plone's
> collective.workflowed. The table will also provide a dictionary of
> parameters that are passed to the states via __init__(). The statemachine
> runtime will initalise and run the object (using action()) and then leave
> the object to get garbage collected. If the state is encountered later, the
> object is reinitialised with fresh params. I imagine the transition table
> will be a model also, providing a rich set of transition manipulating
> functions, along with supporting views. 
> 
> There is also the concept of a substatemachine. This is just a link to
> another transition table, that gets a param dict and returns some symbol
> like any other state. (The difference being it is defined by futher states
> and perhaps substates). 
> 
> I'd also like developers to be able to provide views on their state objects
> in the ZODB in order to alter certain parameters of execution at runtime, or
> maybe view statistics (or whatever). As the system matures, many other views
> will provide runtime information about the runtime's functionality. There's
> a bunch of other functionality that's not really worth mentioning. I hope
> you get the idea. 
> 
> Initially, I envisaged that the runtime would be very separate from
> grok/zope etc..., with grok just storing and publishing objects. However,
> the long arm of grok appears to be influencing my runtime design too! How
> so? Well it would be quite nice to allow developers to write event handlers
> for events triggered from external sources or by application code. Maybe
> acquisition could be useful too somehow? 
> 
> I've hit the point where all this has become a bit too much for me. Can
> anyone validate my design? Suggest how grok may help in other areas? Also,
> how do I approach building a package that will become a facility for
> building a package? What tools should I be looking at here. 
> 
> Sorry for the long mail, and thanks for getting this far! 
> 
> Any help / comments would be warmly received!
> 
> Thanks,
> Paul
>