Rocky,
Couple of thoughts:
1) Can we default the triggerEvent to "Click" when none is provided and/or the behavior is attached to a UIElement that support Click. I'm sure 90% are attached to buttons.
2) Many of the UIFrameworks out there are providing convention based CanXyz on commands and other way of interacting with the UI. How about doing some of that with invokeCommand.
ie) if there exists a CanXyz property for the Xyz method then automatically bind that to IsEnabled? If it is already binded then ignore it.
Thanks
jack
<vent>I hate the web. Hate it, hate it, hate it. I had a nice response to your post, and the web ate it. I hate the web, it sucks.</vent>
To summarize my response, InvokeMethod is obsolete in CSLA 4 (so is Execute). InvokeMethod is replaced by TriggerAction, which is more flexible and VS10 friendly. Execute is replaced by a pre-existing behavior in the Blend SDK that does the same thing, so I can't see why anyone would use Execute.
TriggerAction does default to the Click event. It doesn't alter the appearance of the UI control. That turns out to be restrictive, and gets in the way of good UI designers doing their job. It is better to bind the UI control's IsEnabled property (or Visibility or whatever else) to the CanXYZ property.
fwiw, InvokeMethod actually does have the functionality to enable/disable the UI control as you suggest - but the feature is turned off by default because so many people found it to be a problem for their particular UI style. So I didn't even add it to TriggerAction - though I suppose I could if there was enough demand (but again it would be something you'd enable by choice).
Thanks for the quick response. If it makes you feel better I had to input my post twice as well. It just didn't take the first time.
How would the 'enable by choice' work? A flag in each VM? or a global flag?
When I upgrade all my frameworks to 4.x I really want to clean-up everything and be consistent and try to better integrate everything. I have a horrible hodgepodge of different ways of doing everything as new features were released and/or I better understood how to implement things. I would like my XAML binded controls to default to enable/disable based on the related CanXYZ properties matching to the actions / command method.
If I really care about it I'll overload it and/or use the Visibility.
Thanks
jack
You enable the behavior on InvokeMethod by setting a property to indicate that you want it to auto-disable the UI control. I don't remember the property name, but Intellisense will show it to you.
That's what I'd do with TriggerAction if I went down that road - just add a property you'd set to True if you want it to automatically disable the UI control.
I should point out that this is somewhat complicated by the ability to have many TriggerAction controls handling one UI control's events. If you set more than one TA control to disable the UI control they'd fight and you'd get unpredictable results.
Thanks - that is something else to consider. Maybe I'll only try that approach when I use Commands so it is 1:1.
You mention Commands, as in Commanding - and that is something to remember. There is absolutely no requirement to use InvokeMethod/Execute/TriggerAction. You can use commanding, you can use actual UI frameworks (CSLA is not a UI framework) or you can create your own solutions. There are many options out there, and I only created the options in CSLA to meet certain needs - not to be a full-blown UI framework solution.
I have a hybrid solution right now where the CSLA VM is a childVM of a UI framework. I'd like to try and keep it somewhere along those lines so I'm not replicating all the CanXYZ properties and XYZ methods as stubs from my UI VM to my CSLA object. I'm treating it like a VM and a dataVM or clsaVM. Where I've done it neatly I'm happy. Where I've fudged I'm not so pleased.
But I would like to try to keep my conventions as similar as possible between the two.
Thanks for the advice.
Jack
Copyright (c) Marimer LLC