On 24/08/11 11:34 -0700, Ian Wilson wrote: > I'm not sure if its too soon to bring up these other points so tell me if > so: > > 1. StateAction seems to actually contain the next state as an attribute as > well.
Oops I made an issue, I made a last minute change StateAction inheriting of
StateChoice but this is wrong.
It should be:
class StateChoice(State):
next_state = '' # method name: func()
class class StateAction(State):
action = '' #method name: func()
> 2. Sometimes you'd want to run some code before StateForm, not just
> defaults, and the prior design supported that. I think this applied to all
> the states actually. Can that be unrolled into a preceding Action State
> every time? I'm not sure.
Exactly it was one of the difficulty of the previous design because this
actions list had not clear purpose sometimes it was for default values,
othertimes for just background actions etc.
So now, if you want to perform an action you must create a StateChoice.
> 3. The return values of methods called during state transitions was a big
> source of confusion in the last design. How will this design avoid that ?
> Should the return values themselves be well defined structures?
There is 3 types of methods:
- default: must return a dict with default values (like default_get of
Model) (not commited)
- next_state: must return a str with the next state name (commited)
- action: must return a dict with ir.action.* values (not commited)
> How do you
> manipulate data in the pipeline but still return, for example, the next
> state in the Choice state. This is related to #2.
With a StateChoice.
> 4. I think also there were special data items passed to the states depending
> on the type of state, and depending on if the models were persistent or not.
> How can we get a better handle on that as well? Should that be its own
> data structure or solved with well defined method/function arguments per
> state?
I don't understand.
> 5. Documentation should be involved as soon as possible. I understand heavy
> changes will be made in the code earlier in the process but docs will be
> easier and more relevant if produced in parallel.
I don't beleive in writing before coding because I'm pretty sure there will be
change during the implementation. Also clear design with clear code almost
doesn't need documentation because it is self-documented.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgprjKEcoeNeY.pgp
Description: PGP signature
