How would you define a datatemplate for a Window? What if you wanted to spawn a new window.
On Fri, Nov 5, 2010 at 1:43 PM, Scott Barnes <[email protected]> wrote: > Why aren't you guys using Presenters plus DataTemplates / Views for the > overall orchestration? > > in that Accessing a Presenter to handle the marshaling between View and > Model/ViewModel is perfectly righteous - espec if you cheat and use AutoFac? > :) > > As for mapping ViewModels to Views via Resource Dictionary > > <DataTemplate DataType="{x:Type ViewModels:TestViewModel}"> > <v:TestView /> > </DataTemplate> > > In using this, you don't care what the View is? you just keep talking to > one another via ViewModels only.. what goes inside the View etc is only the > VM's business nobody elses? ContentControl, ItemsControl etc automatically > resolve the View for you so the whole DataContext thing is pretty much not > needed unless you want to see design-time data etc via Expression Blend (but > i've learned to wean myself off that and its pretty disciplined). > > Regards, > > Scott Barnes > > http://www.riagenic.com > > > > On Fri, Nov 5, 2010 at 12:30 PM, Miguel Madero <[email protected]>wrote: > >> Strings are fine most of the time, specially for things like menus or >> links but for most cases I just delegate the decision to the VM of where to >> navigate to or if we need to navigate at all. >> >> On Wed, Nov 3, 2010 at 7:04 PM, Steven Nagy <[email protected]>wrote: >> >>> I usually keep the view and the view model separate, such that the VM >>> has no knowledge of the view. >>> >>> From the view model I might issue a call to navigate to a name, such as >>> “Home”. >>> >>> The navigation service will be responsible for working out what view / >>> VM to build/resolve from that name, and where to load that view (ie in a >>> region, in the shell, in a popup, etc). >>> >>> The nav service tends to change quite drastically between applications >>> though, and depends if you’re using prism or other presentation style >>> frameworks. >>> >>> >>> >>> Of course if you just roll with Magellan you don’t need to think about >>> all this. J >>> >>> I need to spend more time with it, but it’s not the first item on my to >>> do list… >>> >>> >>> >>> *Steven Nagy >>> *Readify | Senior Consultant, Technical Specialist (Azure), Mentor | MVP >>> Windows Azure >>> >>> M: +61 404 044 513 | E: [email protected] | B: azure.snagy.name** >>> >>> [image: Description: Description: sig banner] >>> >>> * * >>> >>> *P** **Please consider your environmental responsibility before printing >>> this e-mail.* >>> >>> >>> >>> >>> >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Winston Pang >>> *Sent:* Wednesday, 3 November 2010 6:03 PM >>> >>> *To:* ozDotNet; ozWPF >>> *Subject:* MVVM in a navigational paradigm >>> >>> >>> >>> Hey guys, >>> >>> >>> I'm trying to apply MVVM in the WPF navigation model. >>> >>> I was just doing some thoughts around it >>> >>> Apart from the rule that the view model shouldn't know about the view, >>> how would a particular view spawn another view, and push it to the >>> navigation service for example? I've been playing around with some ideas of >>> holding a mapping between the View and ViewModel in a global list in App. >>> Then have App register against the messenger/mediator to respond to any >>> other view model's wanting to spawn a new view and navigating it to it. I'm >>> not sure if I'm on the right track. >>> >>> Would love to see how some other people have done it on here? >>> >>> >>> Thanks. >>> >>> >>> --Winston >>> >>> >>> _______________________________________________ >>> ozwpf mailing list >>> [email protected] >>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>> >>> >> >> >> -- >> Miguel A. Madero Reyes >> www.miguelmadero.com (blog) >> [email protected] >> >> _______________________________________________ >> ozwpf mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >> >> > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > >
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
