Hey Brian, That sounds Perfect! I like the idea of simply creating a RunnableInstance and think it fits the architecture well! +50 to proceed down that path.
Cheers, Chris On Nov 8, 2012, at 3:16 PM, Brian Foster wrote: > > hey chris, > > I think i work this out... i'm gonna create a RunnableInstance class... this > will then hold the state, start/end times, type (TASK or CONDITION), and the > class to run (WorkflowTaskInstance or WorkflowConditionInstance). > > -brian > > On Nov 7, 2012, at 3:05 PM, Brian Foster wrote: > >> hey chris, >> >> so i'm going through this WorkflowProcessor stuff and finishing it up... I'm >> trying to make it so that WorkflowProcessor is used by all Workflow >> Engines... WorkflowInstance holds the state, times, etc.. for a Workflow, >> and then a WorkflowProcessor is response for analyzing that WorkflowInstance >> and determining what to run next in the Workflow... in this process i've >> notices that we really don't have any "WorkflowInstance-like" class for >> Tasks and Conditions... A WorkflowTaskInstance is actually the runnable >> task/condition job... I know this would be a big structural change, but i >> think WorkflowTaskInstance and WorkflowConditionInstance should be similar >> to WorkflowInstance (it should hold the state, times, etc... for a >> task/condition)... then possibly introduce a WorkflowTaskExecutable and >> WorkflowConditionExecutable interface, or something like that, which CAS-PGE >> and all other runnable tasks would implement instead... then i've already >> created a version of WorkflowInstance which would hold the >> WorkflowTaskInstances and WorkflowConditionInstance for it's task, preConds, >> and postConds... this way when one loads a WorkflowInstance they would have >> access to all the state, times, etc.. of everything in that workflow... this >> makes is very easy to create a WorkflowProcessor which then is stateless and >> when given a WorkflowInstance can easy determine what is the next thing to >> run or what state the workflow is in... this new design i working toward >> also ditches the whole WorkflowProcessorListener interface stuff, which i >> never liked in the first place, but just never came up with something better. >> >> -brian >
