On Thu, Jan 27, 2011 at 08:48:58PM -0800, Raphael Simon wrote:
>
> > So we have filters and signatures... Filters have a scope, signatures
> > behave more like checkpoints.
> >
> > I think I'd like to implement the filter feature. The signature one needs
> > refining.
>
> And the signature can be fully implemented as a participant but the filter
> cannot so this makes sense. Thank you for the quick feedback loop, really
> appreciate it.
>
> Regarding the filters, would it make sense to also allow defining them
> inline, something like:
>
> ---8<---
> Ruote.process_definition :name => 'my_uber_process' do
> sequence do
> do_something
> a_subprocess :in => [ 'a_field', 'some_other_field', 'orignal_name' =>
> 'new_name' ],
> :out => [ '__result__' => 'new_field' ]
> do_something_else
> end
> end
> --->8---
Hello Raphael,
in this example, shouldn't the filter be replaced with a signature ? (ie
defined in the subprocess ?)
> where anything not explicitly listed in the filters list is not given to the
> subprocess (in) or merged back into the workitem (out).
>
> I guess if you provide the ability to filter using a participant this could
> then be implemented doing something like:
>
> ---8<---
> mappings :input => ...., :output => ...
> a_subprocess :filter => :mappings
> --->8---
>
> with the right implementation for the mappings participant. Maybe the former
> syntax then just becomes a shortcut for the later.
I like the inlining idea.
I'd like to use :filter (and :signature maybe) both with participants and { :in
=> [], :out => [] } one-liners.
Ruote will lookup the name given to it, it could map to a participant, or a
process variable or an engine variable (for filters/signatures shared by the
whole engine).
Participants are powerful because you have the whole Ruby power at your
disposal for filtering/merging/enforcing.
Inlines are quick are limited to a process instance (except when they're bound
in engine variables).
One thing I don't like about the DSL behind the inlines and
theFieldsValidationParticipant is that it's Ruby-bound. I'd prefer to limit
ourselves to the JSON schema (sorry no DateTime or Hash<Hash<String, String>,
Fixnum> recursive fun). I don't want to tie the process definitions to Ruby.
I'd like to avoid implementing (and/or maintaining) a complete type system in
ruote.
I will look at the expanded version of the "inlines".
Give me a bit of time to come up with something we can refine further.
We also have to be clear and differentiate transformations from validations.
:type => 'String', :default => 'run'
is a transformation, while
:type => 'Array<String>', :required => true
is a validation.
Sorry if I drag you in too general a discussion, but I'd like to discuss that
with sufficient altitude in the point of view.
Cheers,
--
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
