Hello Simone,
at first skim through your email to clarify things. Then I will propose a
solution.
On Tue, Jun 07, 2011 at 04:34:15PM +0200, Simone Carletti wrote:
>
> A Ruote workitem con contain additional workitem payload in the fields
> attribute.
A workitem contains workitem fields (sometimes referred as "the payload").
> The content of the fields attribute can be set at any time and the content
> is passed to the next workitem when the previous one is proceeded.
Yes, fields can be set at launch time (second argument to engine#launch), in
the process definition (mostly via the "set" expression) and via participants
(some kind of hook into the running process where workitems are exposed).
> This behavior is perfect if I want persistent fields. But what about
> temporary values I want to stay in the workitem only for the duration of
> that specific workitem?
The duration of a workitem...
>From the point of view of a process instance, there is one workitem at the
>beginning, that gets split when concurrence or concurrent-iterator are reached
>(and later merged). The duration of a workitem could be thought of "from the
>beginning of the process instance until its end".
>From the rest of the email, you seem to think of the duration of the workitem
>as "the moment a participant consumes a workitem to the moment until it's
>consumed by the next participant".
> What I'm trying to accomplish, is to have a place where I can store some
> variables that lasts only for that specific workitem.
(please don't mix variables and fields, process variables != workitem fields)
> When the workitem proceeded and the payload is copied, this set of values
> should be cleared.
So I am wrong, the duration of a workitem for you is "from the workitem
consumption to its proceeding" (the two operations being in the same
participant).
> I'm currently doing this by having a special hash in the fields attribute I
> reset in the Participant#consume each time the workitem is consumed.
> Unfortunately, this approach doesn't work very well because if I use a
> different participant, the hash won't be cleared.
My initial reaction would be that since you are in control of all the
participants in your "real world" you could easily do that cleaning. Also, this
contradicts your previous paragraph where you want the workitem being cleared
of temporary fields at proceed time.
> There are several real world cases for this feature:
>
> 1. I want to be able to temporary set a variable and use it in the
> workflow definition to trigger some special workflow actions
OK, so the temporary values have to be cleaned before or after the next
participant#consume (and not during the #proceed).
> 2. I want to be able to clear a set of variables when the workitem is
> consumed
And those temporary values have to be cleaned before or after the next
participant#consume (wait, I'm repeating myself).
> Is there any existing and clean way to accomplish this?
>
> I came with a couple of solutions.
>
> The first idea is to use naming conventions. For instance, a fields
> attribute called with a specific prefix won't be copied to the new workitem.
> I don't really like this solution because it would make more difficult to
> use the variable in the workflow definition (eg. ...., :if =>
> "{$f:__tmpvalue__} == 10"
${f:__tmpvalue__}
> The second idea is to use a special attribute instead of fields that will be
> ignored when Ruote copies the workitem payload.
> I could also modify Ruote in order to make a new t: notation available. (eg.
> ...., :if => "{$t:tmpvalue} == 10"
>
> What do you think about it? Have you ever encountered this need before?
As indicated above, before, I always trusted people to clean temp values when
they needed it (they know better than I do).
I like your idea. It's a call for a convention.
I wouldn't use ${t:tmpvalue} because there is already ${field}, ${f:field},
${v:variable} and ${r:rubycode} and your temporary fields are clearly "fields".
I'd propose leveraging nested fields (already present in ruote) and do
${t.alpha}
${f:t.alpha}
or
${tmp.alpha}
${f:tmp.alpha}
Then we could make sure that the participant expression clears the 't' or 'tmp'
fields right before any #consume.
It would be quite parallel to the current "params" field which hosts the
participant expression attributes.
small reminder :
participant :ref => 'toto', :task => 'clean room'
hands a workitem that looks like
fields => { 'params' => { 'ref' => 'toto', 'task' => 'clean room' } }
and this 'params' field is cleaned at proceed time.
So 't' or 'tmp' ? I'd also add a #temp or #tmp method to Ruote::Workitem
similar to #params and #fields.
't' could stand for 'temporary' or 'trailing' or 'tail'...
Thanks !
--
John Mettraux - http://jmettraux.wordpress.com
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
