On Thu, Jan 27, 2011 at 03:35:34PM -0800, Raphael Simon wrote: > > In terms of validation of fields I also could not find anything readily > available. I put a FieldsValidationParticipant > <https://gist.github.com/799298>together, wonder if that's going in the > right direction?
Hello Raphael, welcome back. Back a million year ago, when ruote was OpenWFE, a Java workflow engine, participants could be tied to filters. Those filters controlled which fields went to the real participant and then handled the merge when the workitem came back. When I moved to Ruby, I wanted (maybe still want (https://github.com/jmettraux/ruote/blob/7675a47da31485fffd6d160ab2f5592a08a0affe/TODO.txt#L290-291)) to have this feature in ruote, but I realized people built very smart participant implementations, very quickly (it's Ruby), and they all had slightly different needs. Now I realize you want something a bit different, in fact you want this filtering but you also want the "subprocess signature enforcement", am I right ? > so to summarize: > > 1. How does one validate workitem fields in ruote (e.g. the initial workitem > fields)? Ah validation at launch time... I've been resisting this feature for a while : http://groups.google.com/group/openwferu-users/browse_thread/thread/4ea83ccfbc1caa87 http://groups.google.com/group/openwferu-users/msg/8504cf9e065a4607 I guess the launch call would immediately fail. Patrice, in that thread, really wants the process to fail immediately (not asynchronously). What is your take ? > 2. How would a sub-process define the fields it expects and how would the > parent process do the mapping? Via a participant is right. What happens when the expected fields are not here ? Error ? > I could be that I'm completely missing the 'philosophy' being ruote, please > let me know if that's the case... The philosphy on that, is more like trying to delay the implementation decision until it's really needed. So let's look at the current 'way' : ---8<--- Ruote.define do define 'y' do filterTwoIn participany 'z' filterTwoOut end sequence do filterOneIn participant 'x' subprocess 'y' filterOneOut end end --->8--- Quite verbose. One thing we could do is introduce a :filter attribute (on any expression), that would trigger a participant upon applying an yet another upon leaving (replying to the engine). ---8<--- sequence :filter => 'one' do # ... end class LevelOneFilter def consume(workitem) # filter (and keep original) end def on_reply(workitem) # unfilter (merge incoming and original) end end engine.register_participant 'one', LevelOneFilter --->8--- Maybe it's "perverting" participants a bit too much, but it could shorten our process definitions : ---8<--- Ruote.define do define 'y' do participany 'z', :filter => 'two' end sequence :filter => 'one' do participant 'x' subprocess 'y' end end --->8--- What do you think ? 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
