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
<http://stackoverflow.com/questions/612966/keyboard-events-in-a-wpf-mvvm
-application> ), 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
