via the Presenter. At some point someone will pair the DataContext with the
Window at its initial bootstrap. If you keep that logic parked somewhere
where its both generic and liteweight you still plough on as per normal via
the DataTemplate route.
eg:
var dlg = new DialogWindow();
dlg.DataContext = new DialogWindowViewModel();
dlg.Show();
Then inside the DialogWindow itself you have a <ContentControl>
<Window x:Class="MyProject.DialogWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";
Title="DialogWindow" Height="300" Width="300">
<Grid>
<ContentControl Content="{Binding}"/>
</Grid>
</Window>
You're still able to customize the DialogWindow to use a style/etc of your
choosing and house the said Content and again, the ViewModels are still the
first class citizen and knowing specifically which View maps to which
ViewModel doesn't come up for discussion. In the project I'm on, i've never
really needed to know about the View at all and if i need to do something
internal to the view programmatically i do so via ControlTemplates /
GetTemplateChild() routes ...
On Fri, Nov 5, 2010 at 1:05 PM, Winston Pang <[email protected]> wrote:
> 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
>
>
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
