Thanks dude will scope now! On Nov 8, 2012, at 3:42 PM, Brian Foster wrote:
> hey chris, > > i got the initial changes to Workflow, WorkflowInstance, and > WorkflowProcessor in... https://reviews.apache.org/r/7944/ ... let me know > what you think... lol > > -brian > > > On Nov 7, 2012, at 6: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 >> >
