Sorry I missed all that (I had actually looked at these tests but completely forgot after reading the filter expression doc today), looks like you over-delivered ;)
This definitely fits the bill. I'm looking forward to the filter attribute as this is probably going to be how we will be mostly using filters (in the spirit of mapping 'inputs' and 'outputs' to the workitem). I'm thinking the standalone expression is great to do validation (e.g. at the beginning of the workflow and all sub-workflows) while the attribute is what to use to do the mapping for each participant that needs it. I also like the fact that the filter mechanism is easy to use (via Ruote::Filter) since I'm thinking our participants will use this directly to validate the incoming workitem (don't know if it's overkill but at some level this is nicely independent of everything else and could even live in its own gem, rufus-validate anyone?) -- Raphael. On Mon, Feb 7, 2011 at 4:41 PM, John Mettraux <[email protected]> wrote: > > On Mon, Feb 07, 2011 at 04:02:15PM -0800, Raphael Simon wrote: > > > > So I have moved our workflows to use the built-in filters on 'edge' ruote > > and it works great. > > Hello Raphael, > > > Stepping back a little though there is a little bit of confusion in my > mind > > about what this does in relation to what we had discussed. Specifically > what > > I had understood what that you were going to work on a way to filter > and/or > > transform the workitem fields being "given to" and/or "retrieved from" a > > participant. That is a participant would have an implicit > contract/interface > > and the filters could be used to "force" the workitem that it receives to > > abide that contract. So you could have a filter that does: > > > > some_participant :filter => { :in => { 'global_field' => 'a_field' }, > :out > > => { 'a_field' => 'a_result' } } > > > > This would have filtered out all workitem fields other than > 'global_field' > > from the workitem that 'some_participant' consumes and would have renamed > > the 'global_field' workitem field to 'a_field' as far as > 'some_participant' > > is concerned. Once 'some_participant' replies the initial workitem fields > > would be "restored" and the workitem field 'a_field' would now be named > > 'a_result' for the next expression to pick up. > > For now, it's limited to > > ---8<--- > sequence do > filter :field => 'global_field', :move_to => 'a_field' > some_participant > filter :field => 'a_field', :move_to => 'a_result' > end > --->8--- > > I haven't had the time to implement the :filter as an attribute now, I only > did the 'filter' as an expression. > > http://groups.google.com/group/openwferu-users/msg/de967598edea5b5d > > ---8<--- > some_participant > :in => { :field => 'global_field', :move_to => 'a_field' }, > :out => { :field => 'a_field', :move_to => 'a_result' } > > # or > > some_participant > :in => { :f => 'global_field', :mv_to => 'a_field' }, > :out => { :f => 'a_field', :mv_to => 'a_result' } > --->8--- > > > Validation would have been nice to be built in but could have been done > > through participants (like my weak attempt with the > > FieldDefinitionsParticipant). However it seems that you went the other > route > > though were filters really only validate but don't filter nor transform > at > > the moment. > > filtering : > > > https://github.com/jmettraux/ruote/blob/97e83972e1419c4114e81f619c696a65dcf7a0d5/test/unit/ut_22_filter.rb#L31-46 > > transform : > > > https://github.com/jmettraux/ruote/blob/97e83972e1419c4114e81f619c696a65dcf7a0d5/test/unit/ut_22_filter.rb#L178-299 > > I also not had the time to document transformations via the 'filter' > expression yet : > > > https://github.com/jmettraux/ruote/blob/97e83972e1419c4114e81f619c696a65dcf7a0d5/lib/ruote/exp/fe_filter.rb#L241-247 > > > While it's great to have validation built-in into Ruote I can't > > help but think that this should not be the job of filters, maybe a > validate > > expression would be more appropriate. > > 'validate' vs 'filter', makes sense. I mixed both to be able to do things > like : > > > https://github.com/jmettraux/ruote/blob/97e83972e1419c4114e81f619c696a65dcf7a0d5/test/unit/ut_22_filter.rb#L84-143 > > ('and' and 'or') > > > Obviously I could be completely off-base and miss the grand vision behind > > the current design :) Anyway I would appreciate it if you could share > some > > of the rationale behind the current choices you made and where actual > > filtering and transforming fit. > > I have the impression I'm not too far off the mark, I just need some time > to do the :filter attribute (now that I have the filter mecha shared by the > filter expression). > > Wdyt ? > > > Best regards, > > -- > 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 > -- 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
