On 6/20/06, Florent Robineau <[EMAIL PROTECTED]> wrote:
James Strachan a écrit :
> On 6/20/06, Florent Robineau <[EMAIL PROTECTED]> wrote:
>> Actually, I'm working with Hibernate (and Acegi for the security
>> aspect). I'll let you know in case I have anything worth being a
>> persistence example for beanflow.
>
> Great! You using 3.x with the JPA annotations?
>
Yes. I'll let you know when I have something interesting!
Great!
>>
>> Yet I would like to filter the access to the transition methods on two
>> criteria: the user permissions and the previous state. For instance,
>> let's say you need some role for step1 -> step2 and step2 -> step3, but
>> another role for step1 -> step3 directly. Thus in my example I have to
>> know in which state is the workflow at the time the transition method is
>> called so as to determine wether the user has the right to go to step3.
>> How could I do that? With a getCurrentStep() {return this.nextStep;}?
>>
>> And thanks for your previous explanation that did part of the trick.
>
> There's a few different ways we can do this. One of the main ideas of
> BeanFlow is for the 'workflow stuff' to get out of the way and let
> folks just write regular Java code for most things; so we can use
> various regular Java ways to fix things.
>
> e.g. one solution could be to override the setNextStep() to validate
> with Acegi on the current and next step and use both of those values
> to determine if the current security context can be used to change the
> next step.
>
> We could implement that as an interceptor applied to any workflow - or
> just add a method in the Workflow base class that you could override
> in a common base class you use for your workflows
I do agree with you on the principle, but I found it hard to access the
current step... Actually the value of nextStep at the beginning of
setNextStep() is always "null" whatever the previous step may have been,
because at some point nextStep() is called that sets nextStep to null...
Is there any particular reason for this (to avoid recursion, ...)? If
no, removing the line "nextStep = null;" should do the trick.
If yes, I don't see any simpler approach than to store the value in
another variable and retrieve it afterwards... (should it be in the
Workflow class itself or in a subclass which would override
setNextStep() to store the value and call the super function)
My bad :)
Don't know what I was thinking doing it like that ;)
I've just refactored the code a little so you can more easily get the
value of the next step (via getNextStep()) and that the value is not
set to null until asynchronously when the next step is about to be
executed (when the current step becomes the nextStep value).
I wonder if that fixes things for you?
--
James
-------
http://radio.weblogs.com/0112098/
