Scott,
Sounds interesting, specially for composite applications (ala CAB), but I think that could be a bit complex for simpler views/apps, something like what Nikhil did with the Scripts was really simple and straightforward, the only disadvantage I saw was that it added heavy dependencies to the dlr. Miguel A. Madero Reyes <http://www.miguelmadero.com/> www.miguelmadero.com (blog) <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] (871)730-8319 (871)763-0020 Peten #509 Fracc Florida Blanca, 27260 Torreón, Coahuila P "Please reconsider your environmental responsibility before printing this e-mail" The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Friday, 19 September 2008 3:52 PM To: [email protected] Subject: RE: [OzSilverlight] A couple of questions The other benefit of Commands is that essentially you can throw the same command from different areas within your View, which helps reduce coupling of the View with how the overall traffic flows within your Client. You can build a FrontController class which marries both the Event and Command together today. Given that Silverlight has RoutedEvents, one could simply throw an Event (through a homemade EventDispatcher), the FrontController catches it and marries the event with a command and then the command fires a execute method. This in turn will carry out the workflow required in order to achieve a successful command delivery. Upon a result, the command can also throw another command (depending on the data returned) and so on. This is good, as it essentially allows again multiple events to feed off the same commands (but yet have different semantic value) whilst at the same time keeping parts of the overall view abstracted from one another. Martin Fowlers J2EE patterns have some good paths here to follow around this kind of thing. Actually I feel a blog post + code brewing now.. stand by.. (*cracks fingers* - time to put my code where my mouth is!) -- Scott Barnes (Rich Platforms Product Manager) <http://www.microsoft.com/> Microsoft Corp. | Blog: <http://blogs.msdn.com/msmossyblog> http://blogs.msdn.com/msmossyblog | Mobile: + 1 (425) 802-9503 (New!) Twitter: <http://twitter.com/mossyblog> twitter.com/mossyblog | MSN: [EMAIL PROTECTED] P Please consider your environmental responsibility before printing this e-mail From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, September 18, 2008 8:23 PM To: [email protected] Subject: Re: [OzSilverlight] A couple of questions Well, I can't answer for Jordan but I'll try to illustrate. While using the Model-View-ViewModel pattern you have all your UI state and behavior in a separate class. This class is normally set as the data context on your View (XAML page), and you bind everything against this class. Even things like "IsSaveEnabled" to enable the save button. The View communicates back to the ViewModel by commands. The benefit is that you don't have any "btnSave_Click" event handler in your codebehind. Instead your ViewModel waits for that Command to trigger, and then do the work. The benefit of designing your application using these patterns is that you can build quite big applications with (almost) no code-behind. This makes your app easier to test, more maintainable, and easier to work with for a designer using Blend. So what is the problem? The problem is that there is no declarative(XAML) way of triggering animations when thing happens. So if you want to start a storyboard then the ViewModel IsBussy property is true, you will have to write this code by hand. Typically that would involve listening to a PropertyChanged event in the codebehind of the form, and when the ViewModel IsBussy changes to true, then start the storyboard, when it changes to false, then stop it. This isn't the end of the world, but when we're so close to achieving no-code behind it would be nice to go all the way. Also, doing this forces your designer to have a stroyboard with that exact name (say ShowProgressanimation) present, so you as the developer ends up "owning" part of the user experience. If the designer accidentally deletes the storyboard the app will fail at runtime, or perhaps not even compile. The less named elements in your XAML file the better. - Jonas On Fri, Sep 19, 2008 at 1:12 PM, Barry Beattie <[EMAIL PROTECTED]> wrote: > It's a PITA to make apps with all the bells and whistles in XAML then have > to break M-V-VM to "finish" it off. got an example to show what you mean? (just curious/wanting to learn) ------------------------------------------------------------------- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net ------------------------------------------------------------------- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net ------------------------------------------------------------------- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net ------------------------------------------------------------------- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
