Handling Commands Logic

Mar 2, 2008 at 12:01 PM
Hi, I have downloaded 6267. Nice start!

I want to discuss the way commands are handled.
As I can see, the Shell class binds commands through its XAML file, therefore commands are handled in the .cs code behind: Shell.xaml.cs, which is part of the View and not the Presenter. I think that it will be more appropriate to handle commands in the presenter layer (which is what done so far), but why should one direct the Shell or View to call the presenter? Why should I bind commands through XAML?

Since there is no option to redirect XAML to call handlers in a code file other than the Shell.xaml.cs, I think that it will be more appropriate to let the presenter to bind commands, or use a helper class to do the job.

Mar 4, 2008 at 10:15 AM
Hi Tomer

Commands are necessary for allowing human designers to function with Expression Blend. When we think about composite apps build with "Prism" we are also thinking about the role that designers play. In absence of a designer, the person doing the desigining will probably be the developer. The classic story is that the designer will own the UI and decide how things look while the developer will write the business logic (UI-Level) that those UI components will call. The way designer does this is by wiring up to call a command. WPF bubbles up commands so that any of the parents above the focused element that initiated the command, can handle it.

There actually is another option we are looking at for commanding which won't involve hitting the code behind, which is to use custom ICommands which are exposed off a Presentation (View) model. We will be exploring both possbilities of handling commands.

Mar 4, 2008 at 11:50 AM
Hi Glenn,

Implementing ICommand sounds great. In this case, one can implement its own command in the presenter layer (or where the logic should sit of course, so the command), exposing the command through it. This way the designer will be able to bind to the desired command, using a simple binding expression:

<Button Command=”{Binding Path=DesiredCommandExposedByTheViewModel}” … />

One pitfall for using this mechanism is that custom commands implementing ICommand are not routed in the visual tree. This can cause a problem for updating the availability (Enabled/Disabled) of the control binds to this command while the state changes.

There are several ways to work around this problem
1. One can implement a third command-adapter object to expose and handle a Routed Command Binding from one side, and to handle custom command from the other side.
2. One can implement an old fashion OnIdle mechanism for invalidating relevant commands, or by demanding a change notification
on any observed state (which may be difficult for the programmer to implement).

Note that on several cases WPF is not invalidating element availability bind to commands: For example when state changes are not triggered by the UI, and other cases where state changes triggered by the UI but somehow are not invalidated. In these cases, the second option will do the job.

Mar 4, 2008 at 6:44 PM
Hi Tomer

"One pitfall for using this mechanism is that custom commands implementing ICommand are not routed in the visual tree. This can cause a problem for updating the availability (Enabled/Disabled) of the control binds to this command while the state changes."

We actually are working through that. You'll notice if you look in the spike, it has a Presenter hierarchy. We actually see that the handling for commands will reside in Presenters (IPresenter). Because they are in a hierarchy, we can walk up and walk down via our own internal routing. This does not use WPF's visual or logical tree, but we found that Presenters often don't relate to these constructs.

We think potentially we can use the internal commanding to handle enable/disable, visible as well.
Mar 6, 2008 at 1:24 PM
I'm interested in which mechanism (CommandDispatcher or EventBroker) should be used to send messages between different components.

All commands in smart clients as I see are divided into the following types:

1. user gesture commands
___a. from shared UI elements (e.g. application menu or toolbar)
___b. from concrete view (e.g. button on form)
___c. request to other presenter from current as result of user gestures (e.g. showing detailed information in some view about selected item from combobox in other view. Note that I cannot subscribe other presenter to this view event because I want to do smth before and then make a decision about firing event for other presenter.)

2. domain commands (to encapsulate requests to model as described in Potel's paper about MVP)

All commands of (1) are sent to presenters. For (1a) presenter would be application class or shell presenter (BTW: What responsibilities does shell presenter have in spikes? Why don't you use application class? e.g. Acropolis uses application class as "Part" for Shell). Before presenter the user gesture is passed to view, which signals to appropriate presenter. The question is what should be used for this signal. For (1a) Spikes project uses CommandDispatcher and for (1b) it's EventBroker. Obviously EventBroker will be used for (1c). Why cannot you use single mechanism for (1) - user gesture commands?

The enable/disable logic is other responsibility and I think mixing its with commanding doesn't sound good. For example, Jeremy Miller uses MicroControllers like MenuController. http://codebetter.com/blogs/jeremy.miller/archive/tags/Build+your+own+CAB/default.aspx
Mar 6, 2008 at 7:42 PM
Edited Mar 7, 2008 at 10:18 AM
We are now using CAB + SCSFcontrib (WPF port) as the basis for a WPF composite app.
1) Developed our own RoutedEvents mechanism (similar synatx to WPF) which routs over the WorkItemControllers & Presenters tree. ( we don't use CAB's)
2) Used that mechanism to route our implementation of ICommand / RoutedCommand: a command which routs over that (WorkItemControllers & Presenters) tree.
3) Added functionality to the routing nodes (WorkItemControllers & Presenters) to enable command binding (same syntax as WPF command binding) so the CanExecute and Execute logic seats in controllers and presenters.
4) Since our commands are ICommands we can bind via XAML - no command stuff in the view code behind
5) Our command manager pulls the CanExecute status of the commands on IDLE

Problems & Solutions:
A) ICommand interface methods do not get a source argument - no way to pass the real source (i.e the button) to the command handler - a drawback comparing to WPF RoutedCommand. On a composite application I'm not sure that's a problem (the presenter does not want to know the button anyway).
B) Command target management is problematic - Can't use the ICommandSource.CommandTarget property because of its type and because it does not get passed to a ICommand implementation anyway... Would use a map which maps a (source,command)->target but because of issue (A) that is not possible either
1) Added a Target property to the command (value can be any item on our routing tree), this is off course a very big limitation on how generic the command is.
2) If no target is set on the command then the default target is the currently active presenter. (This is a routed command so the actual handling can be in any parent of that presenter)

If you have good directions on solving (B) for Prism, I’d really love to hear them…

Waiting fot Tech-ED2008@Eilat, Israel!
May 11, 2008 at 7:52 AM
Edited May 11, 2008 at 7:53 AM
Hi Amit

DelegateCommand<T> can be used for targetting. You pass two delegates one for CanExecute, and the other for Execute in other words you can determine the target of the delegate. The other thing you may want to look at is the ActiveAwareCompositeDelegate, which targets the "Active" command.