Thanks John. That helped clear things up. 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...
Now, let me see if I can describe the basics at a high level, and you tell me where I'm wrong. - In ruote, you create a process definition. That definition can be a number of types of flows, but the most basic is a sequence. - A sequence steps through a list of participants, handing each a "workitem", which is actually of the class InflowWorkItem. - To start a process definition running, you would create a launch item. This launch item will allow you set keys into it, like a hash, which will end up in the workitem hash when that hash is handed to the participants. - A "workitem", both in Launch form and Inflow form, should be treated as a hash. It's up to you what you place in this hash, and how you use it to make decisions if you wish the flow to continue (assuming you're using some form of looping sequence) or not. - 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. - So at the most basic level, we're talking about an engine that hands a hash to different objects (participants) in a flow based on how the process definition was set up. Is the above correct (or close to being)? If not, where is my understanding incorrect? If so, I'm starting to grasp things (I think). I believe that many more would grasp ruote earlier if you created a very basic quickstart, which outlines things in the most simple manner possible like I've tried to do above. Maybe it exists and I missed it. I've been looking at this too long ;-). So this leads me to another question. It would seem that once the workitem has been handed to the participant, the participant needs to decide if it can continue. This works well in the task example where the participant can simply prompt the user within the block and wait on input...but in a web environment where the interaction is disconnected there has to be another mechanism. I will download the ruote-web2 project and look at how it accomplishes this, but any pointers are welcome. Thanks! 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 -~----------~----~----~----~------~----~------~--~---
