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
