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
>
> > 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)
>
I'm not sure I believe action is that simple. Won't the format be special
for wizards invoking actions? Or well rather maybe if actions were
documented but I don't think they are. Are they documented somewhere?
>
> > 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.
>
What arguments do the 3 types of methods take: default, next_state, action?
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.
>
> > 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.
Right, I think a draft of the documentation should be created after the code
is reviewed. Not before it is written of course but while it is still fresh
on everyone's mind.
Also clear design with clear code almost
> doesn't need documentation because it is self-documented.
>
I agree that clear code helps but it is no replacement for narrative
documentation. If Tryton wants to gain a larger acceptance then it must
produce narrative and complete developer documentation. It is the final
piece missing from the excellent steps you have taken to make Tryton a high
quality open source project.
> --
> 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/
>
Also what about printing? Is that covered by the StateAction ? The old
design had it factored into its own state. Seems like for example it would
be hard to change the report through extension if it was not its own thing.
-Ian
--
[email protected] mailing list
