A Dimarts, 29 de novembre de 2011 09:48:27, Cédric Krier va escriure:
> On 29/11/11 08:59 +0100, Albert Cervera i Areny wrote:
> > A Divendres, 25 de novembre de 2011 19:10:48, Cédric Krier va escriure:
> >
> > class Sample:
> > confirm = fields.Action('Confirm', Equal(Eval('state'), 'draft')),
> >
> > def confirm_action(self, ids):
> > pass
> >
> > I think that something like this has the advantage of:
> > - "Register" the action so we can assign user/group permissions to it.
> > - Clearly states what needs to be the previous "state" before the action
> > can be executed.
> > - All the code is in the same file (no need to jump to XML for following
> > the workflow).
> > - Can be overriden by other modules.
>
> This looks like the Button object I worked (before losing the work due
> to crash disk) to allow to have xml view in separeted file [1].
> So I think it should add some more parameters on it like the type
> (action or method (no more workflow :-)).
What would be the advantage of distinguishing between action and method? What
would be the differences?
> One question I got is when should we test the access right/state.
> For now, this design looks like it is only done on client side except if
> there is some extra code in the method. Or as you said we could use a
> decorator but the issue with decorator is the extension by other
> modules where you lose the fact that the decorator is called first but
> it is perhaps not a problem.
What about overriding __getattribute__ method or something like that in Model?
Too much overhead, maybe?
>
> [1] https://codereview.appspot.com/3991046/
--
Albert Cervera i Areny
http://www.NaN-tic.com
Tel: +34 93 553 18 03
http://twitter.com/albertnan
http://www.nan-tic.com/blog
--
tryton-dev@googlegroups.com mailing list
