>in this example, shouldn't the filter be replaced with a signature ? (ie
defined in the subprocess ?)
I don't think so: the subprocess defines its contract/signature
independently of what the workitem may be at the point it gets called. The
purpose of the filter/mapping here is to define how to match that contract.
It has to be done in the parent process. The signature belongs to a given
sub-process while a parent process has to define the mapping matching the
current workitem when it calls it.
>I like the inlining idea.
Great!
>I'd like to use :filter (and :signature maybe) both with participants and {
:in => [], :out => [] } one-liners.
I'm missing something: how would you use :filter with :in, :out ?
>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).
Makes sense.
>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.
That makes a lot of sense, I wasn't sure where to set the limit but thinking
in terms of JSON helps a lot.
>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.
I am not sure it's that clear, the point being that if a field has a default
value then it doesn't matter that it is required. So a field is either
required (and it's an error if the value is missing) or has a default value
(used if the value is missing). But you're right this wasn't meant to be
pure validation (so the name isn't great), this was more meant to describe
what the interface of the sub-process is.
>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.
Please, by all means :) If anything, it's me dragging you...
--
Raphael.
On Thu, Jan 27, 2011 at 9:36 PM, John Mettraux <[email protected]>wrote:
>
> 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]<openwferu-users%[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
