On 24/08/11 13:05 -0700, Ian Wilson wrote: > On Wed, Aug 24, 2011 at 12:13 PM, Cédric Krier <[email protected]>wrote: > > > 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() > > > > Still missing next state attribute that should be a constant right? I > didn't even see the inheritance before sorry. > > class class StateAction(State): > action = '' #method name: func() > state_after_action = '' #name of state to transition to > after performing action
Ho yes, I was confuse with your comment, indeed the first version (with inhertance is the right). > > > 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) > > > > I'm not sure I believe action is that simple. Won't the format be special > for wizards invoking actions? No it is just an action. > Or well rather maybe if actions were > documented but I don't think they are. Are they documented somewhere? It is in trytond/ir/action.py. I don't think it is useful to document the content of a Model. > > > 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. > > > > What arguments do the 3 types of methods take: default, next_state, action? Nothing. > I remember the inputs being real weird for models that are > not persistent in the database, like a list of tuples where the first entry > is 'add' or 'create', etc. As it is describe before the form fields will be accessed like a BrowseRecord. > Also what about printing? Is that covered by the StateAction ? Yes of course. > The old > design had it factored into its own state. No. > Seems like for example it would > be hard to change the report through extension if it was not its own thing. Don't understand. -- 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/
pgpXm4O0CEUva.pgp
Description: PGP signature
