Temporary field values

[Simone Carletti]

A Ruote workitem con contain additional workitem payload in the fields attribute.

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.

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?

What I'm trying to accomplish, is to have a place where I can store some variables that lasts only for that specific workitem.

When the workitem proceeded and the payload is copied, this set of values should be cleared.

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.

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
2. I want to be able to clear a set of variables when the workitem is consumed

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"

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?

--

Simone Carletti

Application Developer

Site & Blog: http://www.simonecarletti.com

Email: wep...@weppos.net

LinkedIn: http://linkedin.com/in/weppos

Skype: weppos

[John Mettraux]

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

[Simone Carletti]

On Wed, Jun 8, 2011 at 3:53 AM, John Mettraux <jmet...@openwfe.org> wrote:

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).

Yes, exactly.

I always trusted people to clean temp values when they needed it (they know better than I do).

You're right, but if we have several different participants (some of them can be stored participants, other can be block participants and so on) it becomes quite complex (or I would say not-dry) to clone the same clean logic everywhere.

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}

Yes, that was my initial concern. Of course, these values are "fields" but I found the t: additional syntax to be more clear and to leave doors open for further or future enhancements because you are loosely coupling the syntax with the implementation.

I would really love to use t:, but I can live without it since it is just a bit of syntactic sugar.

 

Then we could make sure that the participant expression clears the 't' or 'tmp' fields right before any #consume.

That's amazing.

So 't' or 'tmp' ?

If you're talking about the feature, I would use tmp over t or temp.

The tmp prefix seems to be more widely used to indicate a temporary directory or file.

http://www.ruby-doc.org/stdlib/libdoc/tempfile/rdoc/classes/Tempfile.html

Other good examples are the unix /tmp directory and the Rails /tmp directory.

't' could stand for 'temporary' or 'trailing' or 'tail'...

Agreed, but if you decide to implement the ability to access the fields using a custom notation (instead of nested fields), then I would suggest to use $t as you did with $f -> fields and $v -> variables.

Thank you very much for your reply.

I'm very glad you liked the idea.

-- Simone

[John Mettraux]

On Wed, Jun 08, 2011 at 02:03:10PM +0200, Simone Carletti wrote:
>
> Yes, that was my initial concern. Of course, these values are "fields" but I
> found the t: additional syntax to be more clear and to leave doors open for
> further or future enhancements because you are loosely coupling the syntax
> with the implementation.
>
> I would really love to use t:, but I can live without it since it is just a
> bit of syntactic sugar.

Hello Simone,

I prefer

${tmp.something}
${f:tmp.something}
${field:tmp.something}

over

${t:something}

> Agreed, but if you decide to implement the ability to access the fields
> using a custom notation (instead of nested fields), then I would suggest to
> use $t as you did with $f -> fields and $v -> variables.

$f and $v are clearly mapped to two different/orthogonal concepts, while $t would be a sub-concept of fields.

I'm giving it a night of sleep. ${t:x} would be cheap to implement side by side with ${tmp.x}. I like the latter because it is explicitely a subfield.

Granted, syntactic sugar isn't that bad to have.

I'll implement ${tmp.x} (and possibly ${t:x}) tomorrow morning.

Thanks again,

[Simone Carletti]

Hi John,

I couldn't be more happy with your reply.

So far, I made a custom implementation based on custom participants thus I'll be able to check your implementation very soon and give you an immediate feedback.

Thanks for now,

[John Mettraux]

Hello Simone,

I went with ${t.something}. It's very close to ${t:something} and it can stand for "temporary" or "trailing".

I like the concept of trailing, since those fields really "trail" after a participant and a participant overrides the previous participant's trail.

The concept of "temporary" is more generic and a polite program will tend to clean up its temporary files before exiting. Here if you map a participant to a program, we explicitely leave those temporary fields/files behind.

I've added a #t method to Ruote::Workitem.

Here is the commit :

https://github.com/jmettraux/ruote/commit/e0b0c57dff3362f5ee7419e41c62d3f78dd79a05

Please fire if you have further suggestions, or refinement ideas.

Thanks a ton !

[Simone Carletti]

Thanks John!

I'll try to integrate it on Monday.

I'll pull the master version directly from the repository.

Is there any incompatible change I should be aware of between 2.2.0 and the current master version?

I gave a quick look at the changelog and except for the #reply deprecation, I can't see anything that can break the application.

-- Simone

--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en

[John Mettraux]

On Thu, Jun 09, 2011 at 10:01:16AM +0200, Simone Carletti wrote:
>
> I'll pull the master version directly from the repository.
> Is there any incompatible change I should be aware of between 2.2.0 and the
> current master version?
>
> I gave a quick look at the changelog and except for the #reply deprecation,
> I can't see anything that can break the application.

Hello Simone,

I am sorry for the late reply.

There should be no major issue. Watch the conditional in process definition (especially when comparing strings), the conditions has been tightened a bit (it was looser before, more tolerant on what evaluated to true). If you keep an eye on that, it should be a flawless upgrade.

Thanks again,

[Marcello Barnaba]

Hi John,

I've updated ruote to 2.2.1-pre (6c10f07) into the application to use the temporary fields feature - everything works like a charm :-)

Just to know: do you have any schedule for the 2.2.1 release? No need to hurry - using the Git version is perfectly fine.

Thank you!

~Marcello

[John Mettraux]

On Fri, Jul 08, 2011 at 03:13:53AM -0700, Marcello Barnaba wrote:
>
> I've updated ruote to 2.2.1-pre (6c10f07<https://github.com/jmettraux/ruote/commit/6c10f07>) into

> the application to use the temporary fields feature - everything works like
> a charm :-)
>
> Just to know: do you have any schedule for the 2.2.1 release? No need to
> hurry - using the Git version is perfectly fine.

Hello Marcello,

thanks for the news. Unfortunately I don't have a precise schedule for 2.2.1, it contains a big thing that needs documentation, radial :

http://groups.google.com/group/openwferu-users/browse_thread/thread/1390675a9f6cf14f

I also have to double-check ruote-kit for 2.2.1.

Bundler is so practical.