ICommand - No home in Caliburn Micro?

Mar 23, 2011 at 2:13 PM
Edited Mar 23, 2011 at 2:19 PM

Could someone please confirm there really is no implementation or recommendation  to use ICommand in Caliburn.Micro?

It appears binding the interactivity goo to an action message with guards is a full fledged replacement. It feels like there should be see some kind of support for ICommand as it's so baked into WPF.

 

Also Rob if you are listening the INotifyPropertyChangedEx feels out of place and where is INotifiyPropertyChanging?

Coordinator
Mar 23, 2011 at 2:20 PM

There is no ICommand implementation and there NEVER will be. There is no need. Actions are superior in every way, to the extent that commands can be built on top of them if desired. Read through the forums. There is discussion on this.

What would be your recommendation on INotifyPropertyChangedEx?

I'm always listening :)

Mar 23, 2011 at 2:35 PM

Thank you for the quick reply. I am just digging into this marvelous framework - actually charging forward and implementing it in a 3.5 app.

One aspect of CM I really appreciate is the nod towards a traditional MVP implementation as people have become too focused on MVVM. The most 'under rated' implementation of any 'true composite' UI framework is MVP as evolved by Taligent see http://www.wildcrest.com/Potel/Portfolio/mvp.pdf for a great implementation which IMO the WPF guys recycled. Note the opening paragraph "MVP will enable IBM to deliver a unified conceptual programming model across all its major object-oriented language environments." - Almost 15 years later this still has yet to be fullly realized.

Also pay particular attention to the Class Diagram on page 9. Warning: this will give you chills.

I spoke with Microsoft in an email and they admitted that the original WPF architecture was conceived by Small talk people. The tenants in this wonderful paper still hold true: http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/ModelViewPresenter.htm 

- forget 'design time UI composition' - it;s for your grand parents and infants who require a 'designer' - start thinking of runtime UI composition.

I will keep you posted on factoring out INotifyPropertyChangedEx. 

Thank you for this wonderful framework.

 

 

Mar 23, 2011 at 6:13 PM

>> There is no ICommand implementation and there NEVER will be. There is no need.

I've just come up against this issue....

 Cannot attach type "ActionMessage" to type "BarButtonItem". Instances of type "ActionMessage" can only be attached to objects of type "FrameworkElement".

when trying to add an ActionMessage to a DevExpress control. Now DevExpress have said they will change their Bar control to derive from FrameworkElement instead of FrameworkContentElement in a future release, so need and I've been looking for a workaround.

Indeed, just finding that there is no ICommand feature in Caliburn.Micro, I was about to add a DelegateCommand or RelayCommand as an alternative.
Unless there is a better way?

thanks
John


Mar 23, 2011 at 6:29 PM

 I am still learning the framework but it seems to me action messages could be tied to a UIElement or Visual or DependencyObject to eliminate such an occurance. Actually I just checked and it could use a DependencyObject as per

public class ActionMessage : TriggerAction<FrameworkElement>, IHaveParameters 

where trigger action is 

public abstract class TriggerAction<T> : TriggerAction where T: DependencyObject

Not sure why framework element is required. Perhaps Rob will chime in shortly as he is always watching us ;)

Mar 23, 2011 at 6:34 PM
Edited Mar 23, 2011 at 6:48 PM

Actually this is not going to work as there is a dependency on FrameworkElement.IsLoaded. 

Good luck

Coordinator
Mar 23, 2011 at 6:54 PM

The dependency on IsLoaded is unavoidable due to limitations in WPF/SL's extensibility at lower levels. The WPF/SL teams are not likely to ever fix the problems.

Mar 23, 2011 at 7:09 PM

To put this issue to bed it seems in order for ActionMessages to support FrameworkContentElement the common property 

public bool IsLoaded { get; }

could be better represented as both FrameworkContentElement and FrameworkElement have this property.

Coordinator
Mar 23, 2011 at 7:18 PM
Edited Mar 23, 2011 at 7:19 PM

Yes. I've spoken to the WPF team about that very issue, but I doubt they will fix it. There are a number of things that are similar between FE and FCE that are not represented by a common interface. If you decompile the WPF codebase, you will see the hoops they have to jump through to account for this, when they could just create an interface or two and greatly simplify a lot. In order to simplify CM, I chose to ignore FCE entirely, especially since it does not exist in Silverlight or WP7.

May 4, 2012 at 12:31 AM
jradxl wrote:

>> There is no ICommand implementation and there NEVER will be. There is no need.

I've just come up against this issue....

 Cannot attach type "ActionMessage" to type "BarButtonItem". Instances of type "ActionMessage" can only be attached to objects of type "FrameworkElement".

when trying to add an ActionMessage to a DevExpress control. Now DevExpress have said they will change their Bar control to derive from FrameworkElement instead of FrameworkContentElement in a future release, so need and I've been looking for a workaround.

Indeed, just finding that there is no ICommand feature in Caliburn.Micro, I was about to add a DelegateCommand or RelayCommand as an alternative.
Unless there is a better way?

thanks
John


It seems that DevExpress have changed their tune to "won't fix". So we could really use a bridge between CM's attached messages and vanilla WPF's ICommand - does anyone have any ideas?

Coordinator
May 4, 2012 at 2:17 AM

I can't really justify adding this to the framework. But, you could build it and make a codeplex project out of it :) I'm not sure how much of Caliburn.Micro's actions you would be able to re-use vs. re-write. There's a lot of stuff dependent on FrameworkElement.

May 4, 2012 at 1:32 PM

In the interest of "getting things done", I held my nose and went with standard RelayCommands on the DevExpress controls that inherit from FrameworkContentElement, while continuing to use CM's attached properties elsewhere.

As a side note, has anyone else found that DevExpress controls don't play nicely with the CM binding conventions? So I can't bind a control using <TextBlock x:Name="FirstName" />, I have to go with <TextBlock Text="{Binding FirstName}" /> instead. Otherwise, I think I'm preferring CM to MVVM Light :-)