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

[Lennart Regebro]

On Wed, Oct 29, 2008 at 00:41, Paul Wilson <paulalexwilson at gmail.com> wrote:
> To recap, the configuration of states should be 'viewable', i.e. I'd
> like to have views that configure how states behave during the
> system's execution. From what I've read, views export models, and
> models are objects. So my natural conclusion was that I should have my
> states be models and write views for them. I then reasoned that
> updates to the states should be persistent, and therefore states be
> stored in my ZODB. I can't store a class in there, so I decided to
> create an object from the state and load it.

Sure. That means you want to have a set of persistent state objects in
the ZODB that you can change the configuration for. But for that you
don't need to have one class per state. You only need one state class,
and then you create one instance per state and store them in the ZODB.

> Since states can have
> different initialization parameters depending on where they are in the
> execution or what statemachine runtime is executing it, i don't really
> want to call __init__ on it, just __new__ to create the state.

Creating new objects from the objects? Even if that works, it' very strange. :)
If you need new objects, make the persistent objects factories, and
call a method on them to create the actual state objects, of a
different class.

> Instead, I suppose I should create a parameter object that is
> persistent that gets passed into the state when it is about to be
> used. States can then be designed to receive such an object at
> initialization time.

That works too, but having the persistent objects (which could be
local utilities) be factories is a more common pattern in the Zope
world.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64