On Wed, Aug 24, 2011 at 1:52 PM, Cédric Krier <[email protected]> wrote:
> 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. > I will start another thread about documentation. > > > > > 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 don't understand, I think I am missing something. How will a next_state() make a choice with no inputs? Can you provide a short example of a next state method that uses the prior form whose model is not persisted in the database permanently to make a decision about the next state? > > > 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. > It seems to be factored into its own state here, is it not in a later version ? http://hg.tryton.org/tryton/file/672b92df1ff4/tryton/gui/window/wizard.py#l103 > > Seems like for example it would > > be hard to change the report through extension if it was not its own > thing. > > Don't understand. > You can see above that the report was defined in the wizard definition. > > -- > 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/ > -- [email protected] mailing list
