I get you. Sounds good J Hope to see an implementation.
Is there something similar in Prism for SL? 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: Saturday, 20 September 2008 4:14 PM To: [email protected] Subject: RE: [OzSilverlight] A couple of questions Well let me weigh in where I can J · You essentially create a Façade that handles registering/unregistering command classes. The job of this façade is to marry both an EventClass and CommandClass together (as well as echo the state of the applications mode ie Initializing, Loaded etc). · A CommandClass is essentially a packet of Business Logic. Its job is to execute on a given role, in that it may ask the ModelLocator for state based information or it may request a service (via delegate pattern) to fire a remote response. It can also act as a payload for SubCommands as well (a Command can instantiate other commands within via a Macro Command like pattern). · When you fire an Event via Notification/Observer (ie in our case it just bubbles an event against a known index, so many Listeners can act on the same event) it will the FrontController will automatically interpret this event and fire the command its married to via the executeCommand() method (or however you want to structure this). So essentially you can be anywhere in the view so to speak (typically you want to marry a view with a viewhelper to promote re-use for the view vs simply a code-behind (this is more of code style though so its got no hard fast rule here). The ViewHelper simply needs to fire a Notification event (via a singleton class) and the rest will orchestrate itself. Now, the secret to the orchestration is that you want to have a Model which you bind your controls to, in that pretty much like old school DataSets, you simply bind the controls to properties within respective models. When you fire a command, what you want to do is via the executeCommand() update that given model as this will automatically update yoru view throughout (you can do some interesting binding routines here and get away with it). The trick for us however is you need to ensure the INotifyPropertyChanged is implemented in the Model, as you need to tell the controls that new data is in the model and they should refresh (we hope to clean this up in future releases may I add, as yes its an absolute pain in the royal butt). I plan on releasing some code via new project Ive started called Nexus (which Im extremely excited about and thank this list for inspiration for such an idea). http://blogs.msdn.com/msmossyblog/archive/2008/09/19/introducing-ms-project- nexus.aspx From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Madero Sent: Friday, September 19, 2008 7:11 PM To: [email protected] Subject: RE: [OzSilverlight] A couple of questions 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 ------------------------------------------------------------------- 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
