Silverlight: Thoughts on including an ICommand implementation in the Silverlight Toolkit?

[David Anson]

Hi gang,

 

I know it's weird to mail the WPF list with a Silverlight question, but I know you guys have a lot of passion about this and I believe have already done a couple of implementations of concrete ICommand subclasses.

 

Josh: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Laurent: http://www.galasoft.ch/mvvm/sample1/, http://blog.galasoft.ch/archive/2009/09/26/using-relaycommands-in-silverlight-and-wpf.aspx

 

Now, I'm NOT looking to start a religious war here. :) But the question came up internally and I wanted some feedback. If I were to include an ICommand subclass in the Silverlight Toolkit, I would probably end up with something very much like what Josh calls RelayCommand in his post above. In case you don't know me: I like simple and I dislike dependencies.

 

Do folks think that level of support is enough to start with, or are there additional ideas in Laurent's post - or anyone else's - that you think would need to be included? Are there special constructor forms you'd really want to see? Helper methods you "just can't live without"? That kind of stuff.

 

I can't promise I'll be able to do any of this, but I knew if I asked here, I'd probably get some great feedback.

 

Thanks in advance!

[Sacha Barber]

I do not mind either, they are similar enough.

--
Sacha Barber
sacha....@gmail.com

[Josh Smith]

I've used my RelayCommand on a bunch of real projects and never needed to modify it to meet some new need.  I'm not saying that "mine is better because it's mine" but I'm happy with it.  With that said, I've never used anyone else's version of this class, so I'm not exactly in a position to compare and contrast.

Josh

[Sacha Barber]

I have used Joshs/Marlons/ and Laurents and they are all much of a muchness.

--
Sacha Barber
sacha....@gmail.com

[Laurent Bugnion, GalaSoft]

Hey David,

 

My RelayCommand is based on Josh's one, and almost not modified. I only fixed a bug in the Silverlight version of it, and reported the bug to Josh as well, so it might be fixed there too (it had to do with the initial query of the CanExecute method, so that a bound control would be disabled from the start if CanExecute returns false).

 

Regarding external dependencies, I hear you. Feel free to use my code in any way you want. In fact for some time I wanted to use the WTFPL license (but eventually I used the MIT one ;)

http://sam.zoy.org/wtfpl/

 

Cheers,

Laurent

[Glenn Block]

David

P&p ships delegate command in Prism. Might be good to consolidate.

Glenn

--
Sent from my mobile device

[David Anson]

Thanks, everyone! The general consensus when I ran this up the flag pole in the office was that the existence of Prism and its support for WPF and Silverlight (as well as all the other fine frameworks out there!) meant that there was not a specific need to dabble in the MVVM arena with the Silverlight Toolkit. Therefore, I'm not currently planning on introducing a concrete ICommand class to the Silverlight Toolkit - instead we'll refer interested parties to the existing, more dedicated frameworks for their commanding needs.

Thanks again for all the fantastic feedback!

[Michael D. Brown]

I'll repeat what I said before. I'd prefer that the framework teams (WPF and
Silverlight) work on doing those things that only they can do (e.g. adding a
VisualTreeHelper to SL3) to enable the community to do more. That being
said, the Silverlight Toolkit team is not the framework team. I feel that a
Silverlight Toolkit would not be complete without a RelayCommand or its
equivalent. There is value in having it directly in the toolkit rather than
saying if you need an ICommand implementation look that-a-way.