Tom Sugden - 11/Aug/09 09:57 AM This looks good and will make the task of porting a Cairngorm or Parsley 1 application easier, since the command pattern and Front Controller are widely applied. I like the explicit distinction between synchronous and asynchronous commands, which is only implicit with Cairngorm. Presumably this allows asynchronous commands and Spicelib Tasks to be unified, so a command might be, for example, a sequential task group? This is certainly favourable to the problematic SequenceCommand approach sometimes applied.

Jens Halm - 11/Aug/09 06:39 PM How would you like to see the Task Framework supported? The SequentialTaskGroup itself has no method that could be used as a MessageHandler. So I'm not sure how you would declare the group in the Context? I thought that you then would create a normal class that configures a regular method with [Command] and then create and use a TaskGroup internally? Do you think this could be a smoother experience?

Tom Sugden - 12/Aug/09 11:01 AM Hmm. Perhaps it would be useful to be able to call a no-args method in response to a message? Then a task could be configured in the context, and created and started in response to a message. There are certainly other cases where a developer only needs a method call in response to a message, there being no need to extract data from the message itself. If the commands were unified with tasks, Parsley would need to manage their lifecycle based on complete and error events, such as those dispatched by Task.

Jens Halm - 12/Aug/09 12:51 PM - edited Supporting no-args methods would be possible. Just have to think about how I handle the case then when there is no parameter (where I can inspect the messageType) *and* no explicit messageType declaration. Two possible options: A) throw an Error or B) interpret it as "I want to handle all types of messages". I think B) does not make much sense if you don't get a reference to the message instance, so I think I'll go with A). For supporting Tasks, I'm not sure. First, although the Task Framework is part of the Spicelib it is currently not a dependency for Parsley. Then I am not sure how the preferred way of building sequences of operations with Parsley would look like. Probably it would be better to support it in a loosely coupled manner, like with other services too. This could be achieved through the new order attribute. It would allow to define parts of sequences in different configuration files, swapping one part without affecting the other and so on. An example could look like this: <Object type="{LoadUserCommand}">     <AsyncCommand method="loadUser" order="1" block="true"/> </Object> And anywhere else: <Object type="{HandleUserPermissionsCommand}">     <Command method="handleUserPermissions" order="10"/> </Object> While the order attribute defines the execution order, the block attribute makes sure that subsequent message handlers wait until the async command has finished executing. If the async command throws an ERROR event instead of a COMPLETE event, the second command will never be invoked. Commands could even use the message instance itself to add information to it for subsequent handlers to avoid the need to always have a pair of XXX_REQUEST and XXX_RESULT messages (although that is a matter of preferences if one likes this style). Of course it could be that someone would prefer explicit sequence declarations like this: <CommandSequence ...>     <Command .../>     <Command .../> </CommandSequence> But this would be difficult to solve with the flexibility the existing configuration options offer. As for explicit support for Tasks: Have to think about it. I guess this could be supported on top of existing mechanisms. It probably *is* automatically fully supported if I just allow no-arg handlers. Will check that.

Tom Sugden - 12/Aug/09 02:05 PM - edited I don't think introducing a dependency on the task framework is justified, but I do think that being able to invoke no-arg methods in response to messages would be generally useful.

Vincent Spallek - 24/Aug/09 06:10 PM Will it be possible to dispatch commands from unmanaged code, i.e. without using the [ManagedEvents()] tag? I cannot think of a mechanism to achieve that though ...

Jens Halm - 24/Aug/09 07:08 PM - edited An unmanaged object would need at least a reference to a Context instance. It can then dispatch with context.messageRouter.dispatchMessage() which would be routed the same way as a ManagedEvent.