On Tue, Aug 23, 2011 at 5:36 AM, Cédric Krier <[email protected]> wrote:
> On 23/08/11 08:27 -0400, Sharoon Thomas wrote:
> >
> > On Aug 22, 2011, at 5:15 PM, Cédric Krier wrote:
> >
> > >
> > > class Example(Wizard):
> > > start = 'init'
> > > end = 'end'
> > >
> > > init = StateForm('account.invoice', buttons=[Button('Cancel'),
> Button('ok', 'step2')],
> > > default='default_invoice')
> > > step2 = StateAction('action_step2', 'next_step2')
> > >
> > > def default_invoice(self):
> > > return {
> > > 'code': 'ABC',
> > > }
> > >
> > > def action_step2(self):
> > > party_obj = Pool().get('party.party')
> > > # self.init.party is a BrowseRecord for the party filled in init
> Form
> > > party_obj.write(self.init.party.id, {'invoiced': True})
> > >
> > > def next_step2(self):
> > > return 'end'
> >
> > Is this going to be invoked from the pool too ? I assume the mechanism of
> loading from pool will remain the same (and an _name attribute).
> > And will it support inheritance just as with regular models ?
>
> Yes of course but I think it will store class in the pool instead of
> instance.
>
> --
> 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/
>
Hi,
I think objects are a good idea and fit with the rest of Tryton.
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.
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.
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? 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.
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?
So for #3 and #4 simply, how can we do a better job of defining the inputs
and outputs for states.
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.
Looking forward to new wizard design,
-Ian
--
[email protected] mailing list
