Custom Tasks as methods.

Nov 6, 2008 at 3:20 AM
This is a cool framework and exactly what I was looking for. One question though, Can I specify methods in the custom tasks instead of classes during the state transitions. i.e can we move the TaskDescriptor attribute on the method names. In the following example I want to have DraftAssignment and AssignAssignment as methods inside a single class. These methods are workflow methods and I feel its good OOProgramming to keep them as methods. Is that possible?

state @AwaitingAssignmentCreation:
 when @AssignmentDrafted     >> @Draft
 when @AssignmentAssigned    >> @Assigned
 when @AssignmentAccepted    >> @AssignedClosed
 
on_enter_state @DraftAssignment, "on_enter_state(@AwaitingAssignmentCreation)"
on_enter_state @AssignAssignment, "on_enter_state(@AwaitingAssignmentCreation)"
Nov 7, 2008 at 6:20 PM
agilefx, I am in the same boat as you. I would like to specify method names in the custom actions. PlasticLIzard?  ernstnaezer?? anyone??
Coordinator
Nov 8, 2008 at 3:47 AM
Interesting thought. What object would you expect the method names to bind to?
Nov 9, 2008 at 1:14 AM
Instead of tying to a single object, we could attribute both object and method names and specify the combination in the state change statement.

on_enter_state @ObjectName::MethodName, "on_enter_state(ToBeInvoiced)"
Coordinator
Nov 9, 2008 at 5:11 AM
That makes perfect sense to me. Any chance you'd like to submit a patch? :) If not, I'll take a look at this as soon as I get a chance. I can see it being a pretty useful enhancement, if you have a lot of related tasks that would fit nicely into a single class.
Coordinator
Nov 10, 2008 at 6:03 AM
Edited Nov 10, 2008 at 6:05 AM
Boo fought me on this one, but I was able to get something working, although not really ideal. Let me know if this is what you were thinking, and if so I'll ponder a better DSL syntax (probably by switching from Boo to Irony.net or TinyParser - coming back to this project after a long absense made me realize using Boo as a DSL platform is sneaky, but not so straightforward unless you program in boo all the time.

Anyway, to achieve what I think you are asking for, you will need to enclose your task name in full quotes, instead of using the @ modifier. For instance, instead of this

on_enter_state @TaskName::MethodName, "arg1","arg2"

you would do this

on_enter_state "TaskName::MethodName", "arg1", "arg2"

TaskName is still the name you defined in your attribute, but MethodName can be the name of any method on your task. If you define your method signature to accept a parameter of type TaskContext, then the current TaskContext will be passed in and should always be of type StateMachineTaskContext, so cast freely. Alternatively you can have an argless method, but those are your only two choices. Also you can return a value from one of these methods if you like, but they can also be void. See the test fixture for CustomExecMethodWrapper and the state machine itself for examples of usage.

Also, if I totally misunderstood your request, let me know that as well :)