Some thoughts on the RoutedCommand design

Some thoughts on the RoutedCommand design | MS Tech News

Some thoughts on the RoutedCommand design | MS Tech News — Sun, 02 Nov 2008 03:59:58 GMT

PingBack from http://mstechnews.info/2008/11/some-thoughts-on-the-routedcommand-design/

re: Some thoughts on the RoutedCommand design

Rob — Sun, 02 Nov 2008 22:23:17 GMT

John, can you provide some mocked up code and talk in more detail about what types of problems this would solve - aside from mapping of multiple gestures to a "concept."

re: Some thoughts on the RoutedCommand design

Neil Mosafi — Mon, 03 Nov 2008 02:42:42 GMT

I like this idea. When you write a ViewModel and you expose an ICommand, it would be nice to be able to natively wire up the input event to the command and still have the benefits of the existing RoutedCommand framework. Your proposal seems to solve that problem by segmenting the command behaviour from the command execution. Whilst RoutedCommand uses inheritance to solve this, verbs would use composition to do it meaning you could get the routing of commands with any ICommand implementation.

I think this simplifies things - as you said commands are just a special type of input gesture so why treat them differently?

re: Some thoughts on the RoutedCommand design

Stefan Olson — Mon, 03 Nov 2008 06:22:15 GMT

John,

I agree with Rob that it would be good to have some example code to try and work through in my head exactly how this works.

Your post inspired me to write up on my blog some of the issues that I had with routed commands and how I solved them by creating what would what I've called targeted commands, which is similar to what is in blend but on a much more simplified scale: http://www.olsonsoft.com/blogs/stefanolson/post/Targeted-commands-in-WPF-in-Silverlight.aspx. I will be making the source code to this system available in the near future, but it is just another in the many different ways of handling commands that are out there in the community.

Your indication this post is that it would still continue to route the same way routed commands do, which as I described my article is not always suitable.

One thing I'd really like to see solved with commands is the issue of indicating your checked state. Right now there is no easy way to check a toggle button from your CanExecute, if the text selected is bold. Are there some plans to improve that? I haven't yet checked out the ribbon control to see if they have come up with a solution in their code.

I do have to add how nice it was in WPF that the CommandManager works with ICommands, so with my TargetedCommand class I get the same CanExecute behaviour as routed commands. I had not expected it to be quite so simple!

...Stefan

re: Some thoughts on the RoutedCommand design

John "Z-Bo" Zabroski — Fri, 14 Nov 2008 10:28:22 GMT

There's a lot to be said for allowing failure if one wants to have a high probability of success. The problem with the WPF Command subsystem is the same as the problem with the man who is 200 lbs overweight with broken health -- there may not be any good solutions today, only some that are worse than others. The good solutions were only available 5, 10, 20, and 30 years ago.

Be careful. WPF's biggest flaw is that it's not purely OO, but rather some hybrid of OO and architect's-kitchen-sink. You want to get rid of RoutedCommand, but fail to explain to the layman why RoutedCommand is a poor idea for a public API, and an especially poor API for a supposedly OO UI framework.

RoutedCommands fundamental flaw is that it doesn't allow a delegation model: Any external information the object needs to get the task done is passed to it. RoutedCommand doesn't do this. Rather than being given routing instructions, it routes the object. You also can't pass additional details, such as whether this command gets logged (perhaps to more easily implement Undo stack. OO systems should feature objects that never ask other objects for information to do something; instead, the object should ask the peer object that already has the information to do the work.

It turns out that my comments are correct both in theory and in practice. It turns out OO principles is a really common concept, as Stefan has roughly created such a solution with his ICommandReporter argument to his TargetedCommandManager.

But how much more theoretical can I make my argument and still be attached to sound practice? It turns out routing is a general concept in distributed, real-time systems. In particular, you want a distributed event bus with subscription-based routing and policy-driven management of discovery and federation. A TargetedCommand, and even Josh Smith's RelayCommand, are just different routing protocols for building distributed, discoverable, federated systems. The interfaces for these commands also create adapters to stabilize what kind of subscription you want: Pruning what objects or sub-tree of objects to send commands to is also theoretical, and known as quenching (activation/deactivation of event sources). A command by itself should never know its routing protocol. That's the job of the sender: picking first class mail over 27th class mail, etc. Delegate the routing protocol, and also have CommandManager keep several journals, allowing journaling to be delegated to various journaling algorithms. The journaling algorithms can also, in turn, be event-based and give birth to event monitoring tools.

Similar stuff could be done to fix the silly design of the journaling system for page navigation, which is also non-OO, and completely architect's-kitchen-sink.. All my comments are backed up by theory, and not from-the-gut thought as to ideal abstractions. Your Verb concept didn't lose me, I've done similar designs in Swing based on Swing guidance, though your design seems iffy and non-OO. It seems very inheritance-based, underutilizing delegation? Verbs also need semantics, not syntax. Am I cutting on a dime, escaping a linebacker, or am I cutting text from a buffer? Seems like what you really want support for is Multi-Events, the event analog to multi-methods. And I'd agree. Writing tk code in lisp is far more expressive than other languages for this reason. Unfortunately, .net languages don't support multi-methods or multi-events; it is based on the type binding system of the CTS. To do what you seem to truly want, you'd need to talk to the CLR folks about changing the design of type binding. Sounds like a problem for MS Research? Even then, as a MS Architect, you need to expose an API usable from all .NET languages...

Also, I feel I've had a hard time convincing other programmers of sane design in my life, so I'll settle for a religious victory: FrameworkGesture fits better. AbstractGesture is a little too artistic for me, and also seems to go against WPF naming convention for ABC's.

re: Some thoughts on the RoutedCommand design

John "Z-Bo" Zabroski — Fri, 14 Nov 2008 10:56:24 GMT

@Verbs in turn act like input and route through the visual tree until they find a Binding that maps them to a ICommand on the ViewModel.

I'm not 100% sure how you'd do this, but my reaction is, Why make Binding decide? Does DataContext's separation from Binding guarantee a Binding+DataContext will map correctly? Probably not... Sometimes you want to tightly bind these together, which explains all the cruft on the Binding/MultiBinding interfaces, such as ElementName. Something I'd have to think further about, as standalone Binding could create a nasty schroedinbug. I suspect most bugs in WPF apps to be schroedinbugs from the inheritance context mechanism.

re: Some thoughts on the RoutedCommand design

johnzabroski — Fri, 14 Nov 2008 23:06:29 GMT

@Neil

@Whilst RoutedCommand uses inheritance to solve this, verbs would use composition to do it meaning you could get the routing of commands with any ICommand implementation.

Using composition still doesn't solve the underlying problem that the design is non-OO.

Composition (through interfaces) doesn't equal OO. What composition gives you is resiliency to bugs resulting from "fragile base classes", or, as recent research points out, fragile middle classes. In a nutshell, good use of composition frees you from making assumptions about implementation details. However, good use of composition can be done with structured programming and functional programming.

It's delegation that is missing, in many places, from WPF. Examples include navigation and controltemplates. Without delegation, WPF apps still feel very much like VB6. RoutedCommands actually map directly to the VB6 way to do things: Frame/Controller paradigm, where the controller ends up knowing too much.

re: Some thoughts on the RoutedCommand design

Karl — Sat, 15 Nov 2008 01:03:35 GMT

Sounds interesting. A number people have been critical of RoutedCommands as they are implemented.

You may want to check out the Composite Command concept over in the Prism project

http://hirentechie.wordpress.com/2008/08/27/microsoft-prism-composite-wpf/

and

http://www.sitechno.com/Blog/SpikesWithPrismCouplingCommandsToViews.aspx