[Grok-dev] Grok/Zope Technologies for State Machine
Paul Wilson
paulalexwilson at gmail.com
Tue Oct 28 19:41:42 EDT 2008
Thanks for your comments.
No, you're right. I think a part of me wants to put the actual state
class in the ZODB and have various statemachines (running
concurrently) getting instances from it, but this is backwards. My
requirements seem inverted, because I want 1 class but several
non-persistent objects who live for the duration that the statemachine
is executing that state.
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. 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. When a
particular statemachine wants to use and execute a state, it creates a
local copy and initializes it with whatever parameters are
appropriate. But this is contorted somehow, and I don't think I
thought it through properly.
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. A view can be written for this configuration
object, and I would get the desired effect. I can see a downside with
this approach; developers would have to write states and configuration
objects and views on those configuration objects.... But it's the best
I can come up with for the time being.
Paul
2008/10/27 Lennart Regebro <regebro at gmail.com>:
>> 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.
>
> Here you lot me. Should you only have one instantation of each class?
> And it should be persistent? There are reasons to do this of course,
> usually when it comes to configuration, but it doen't sound to me like
> a configuration issue here.
>
> --
> Lennart Regebro: Zope and Plone consulting.
> http://www.colliberty.com/
> +33 661 58 14 64
>
More information about the Grok-dev
mailing list