You might consider building the graph in advance and use it for planning purposes.
Bruce B. On Thu, Nov 8, 2012 at 4:01 AM, Chris A Mattmann <chris.mattm...@gmail.com>wrote: > 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 > > > >
