I must admit, I've never been a fan of commands. I've always managed to not have to use them (especially when they didn't exist in Silverlight). I'm sure they are great but I prefer to keep things simple and always felt commands were overly complicated to implement and learn/understand.
And here I was thinking it was just me. :) On Mon, Nov 8, 2010 at 9:17 AM, <[email protected]> wrote: > I totally agree with the rant. The ViewModel should just expose the method > to perform the behaviour, not implement/expose plumbing. > > > > Carl. > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Miguel Madero <[email protected]> > Sent: Sunday, 7 November 2010 5:35 PM > > To: ozWPF <[email protected]> > Subject: Re: Events to command binding > > > > BTW I love the CallMethodAction in Blend so I don't have to define Command > in my ViewModels. It feels more POCOish. Just a public method. If I need the > IsEnabled I just add a property and bind it to either IsEnabled or > Visibility. > > <rant> > > Commands are just too messy and feels like leaking view concerns into my > VMs. Just for the same reason I don't expose properties of type Visibility, > I don't like exposing ICommand. > > Setting purity aside, it's just too much work, create another property that > delegates on your method, initialise it in the constructor, then find ways > to actually be able to call that from code... naaa. That's just messy. > > </rant> > > > > On Sun, Nov 7, 2010 at 7:26 PM, Miguel Madero <[email protected]> wrote: > > +1 for Blend Triggers and Actions > > +1 for Code Behind for uncommon scenarios as a second option. > > On Tue, Nov 2, 2010 at 2:36 PM, Paul Stovell <[email protected]> > wrote: > > There is an Expression Blend trigger action that can invoke a command IIRC. > That’s probably the easiest way. > > > > Caliburn also has a nice approach of mapping an event to a ViewModel method > via an attached property – something like <Button cal:Message.Attach=’[Event > MouseOver] = DoSomething()’ /> > > > > Personally, if there’s no command out of the box and it’s not a common > scenario, I’m quite happy to write a plain old event handler and invoke the > method on the VM manually. There’s nothing wrong with a little code behind. > > > > Paul > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Greg Keogh > Sent: Tuesday, 2 November 2010 2:31 PM > To: 'ozWPF' > Subject: Events to command binding > > > > Some have scoffed when I expressed dismay at the artifice that creates > binding. I’ve just discovered that I’m wasting hours of time converting > events into commands. For example, iIt took me an hour to find a piece of > sample code that converted KeyDown on TreeView nodes to a binding (found > HERE), but it needed delicate merging with existing ICommand processing > classes I use. > > > > I estimate that 50% of the time I spend writing WPF apps is wasted trying to > follow MVVM and bind the control XAML to my controller class. It seems that > every other man and his dog who is trying to follow the MVVM pattern as well > has created untold amounts of confusing and conflicting code for the > purpose. I’m sick of searching for and finding jumbles of code that I have > to tidy up and include in my projects. > > > > I feel compelled to write a small infrastructure that allows > event-to-command binding in a generalised way, but I’ll bet it’s been done > already (multiple times and in multiple ways). Has anyone got any > suggestions or comments on this? Surely I’m not the first person in the > world to have stumbled across these hurdles. > > > > MVVM would be wonderful if all of the wiring was just built-in. > > > > Greg > > > > > > _______________________________________________ > > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > > -- > Miguel A. Madero Reyes > www.miguelmadero.com (blog) > [email protected] > > > -- > Miguel A. Madero Reyes > www.miguelmadero.com (blog) > [email protected] > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > _______________________________________________________________________________ > > This email has been scanned by the Bankwest Email Security System. > _______________________________________________________________________________ > > _______________________________________________________________________________ > Unencrypted electronic mail is not secure and may not be authentic. > If you have any doubts as to the contents please telephone to confirm. > > This electronic transmission including any attachments is intended only > for those to whom it is addressed. It may contain copyright material or > information that is confidential, privileged or exempt from disclosure by > law. > Any claim to privilege is not waived or lost by reason of mistaken > transmission > of this information. If you are not the intended recipient you must not > distribute or copy this transmission and should please notify the sender. > Your costs for doing this will be reimbursed by the sender. > > We do not accept liability in connection with computer virus, data > corruption, > delay, interruption, unauthorised access or unauthorised amendment. > ___________________________________ > ____________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > _______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
