On Thu, Jan 27, 2011 at 10:10:44PM -0800, Raphael Simon wrote:
>
> > 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.
Understood. Transformation it seems.
> > 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 ?
For now, I'm thinking something like :
---8<---
engine.variables['filter1'] = { :in => [], :out => [] }
# ...
Ruote.define do
x :filter => { :in => [], :out => [] }
set 'v:filter0' => { :in => [], :out => [] }
x :filter => 'filter0'
x :filter => 'filter1'
x :filter => 'participant_name'
end
--->8---
> > 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.
Maybe we could have a look at things like JSONpath or equivalents.
> > 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.
Understood.
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
