The whole point is to have as little code as possible. And doing storyboards in code is deff. not the solution to this problem. The whole point is to use patterns that lets your designer own the user experience and not depend on code and Visual Studio. But sure, procedural animations is a powerful technique, and useful in a bunch of cases (where to want some randomness/dynamicness to the animation.
On Fri, Sep 19, 2008 at 1:41 PM, .net noobie <[EMAIL PROTECTED]> wrote: > but you can write storyboards in code, not that is is as easy as just drop > and drag in blend > > > On Fri, Sep 19, 2008 at 1:23 PM, Jonas Follesø <[EMAIL PROTECTED]> wrote: > >> 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 >> > > > > -- > .net noobie™ > > ------------------------------------------------------------------- > 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
