On Thu, Mar 5, 2009 at 7:04 PM, John Mettraux <[email protected]> wrote:
> > On Fri, Mar 6, 2009 at 2:21 AM, J B <[email protected]> wrote: > > > > That, along with reading other threads here and playing with your todo > list > > example (which to me is a much better quickstart) in a debugger... > > Hello, > > oh really, then I will link to it as well from the quickstart page, > I'm sure you're not the only one who prefers the todo list. > > (isn't the debugger a bit of an overkill ? simple "puts" or "p" calls > should do the trick and save you precious time... OK, I shut up) > Ha...well, I really like using rdebug to look around ;) > Yes, but you can also simply launch a process by passing the definition : > > engine.launch(pdef0) > > or > > engine.launch(%{<process-definition name="x" revision="y"> > <participant ref="toto" /> > </process-definition>}) > > or the URL to the process definition > > engine.launch(" > http://documents.example.org/pdefs/pdef0_20080405_capex.xml";) > > In those 3 examples, the initial 'hash' is empty. > > Launchitems are useful for pre-filling workitems. > Great...this is very good to know. > > > When you speak of proceeding a workitem, you're simply stating that the > > current participant doesn't do anything to prevent that workitem from > moving > > to the next participant. If your participants don't really do anything at > > all, the workitem will proceed through a sequence unimpeded. > > Sorry for the vagueness of this "proceed" concept. Human participants > usually have to explicitely send back the workitem to the engine for > it to proceed (resume) in its process instance. > I see....now is the way you do this documented anywhere? Both the handing to an external recipient and the replying from? > You'll be ready to write documentation soon ;-) Out of curiosity, > which workflow engine are you currently using ? > Heh....not quite yet, but I feel like I'm getting somewhere. ;) Regarding what workflow engine we're using...well...none at the current time. We developed an in-house application that flowed documents through approval processes years ago, but I to call it a workflow engine you'd have to squint and pretend a little. The capabilities of the flows themselves are very limited...mostly sequential. This is the application I intend to replace with ruote...we have requirements for more complicated flows. I've spent some time researching JBPM, Intalio and Grailsflow...but I've been doing Ruby for too long and going back to enterprise Java is just depressing. Too much enterprise...not enough productivity. > > Ruote-web2 and ruote-rest do that via an "inbox" mechanism. > So maybe that documentation I ask for above is in fact the code our ruote-web2. I was unable to dig into that today, but will tomorrow. > > The todo example is super-vanilla, ruote is thought for an > asynchronous world (with sync being a subset of async). Maybe the > danger of the todo-list quickstart lies in making people believe that > ruote is just about synchronous question/answer cycles... I definitely think ruote would benefit from more demonstrative example apps for things people typically try to do in a business environment with workflow engines. I'd say at least 50% of workflow apps in your typical business involve document routing...at least in my experience. Might be an interesting sample...if I get far enough along perhaps I can contribute something. > > Best regards, thanks for the feedback, > Thank you for your time. John --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
