|
I'm starting a new WPF app. The app's visual layout is pretty simple[^].
I have done apps like this before, but I'd like to revisit the way I do this.
Basically, the main content area contains a Content Presenter that is bound to a property called MainContent in the MainWindowViewModel. Then logic in the MainWindowViewModel determines which view to bind. The main content is then dynamic based of business logic.
For example, after installation there will be a series of views, like a wizard, that walks the user through the intial setup. Then, once up & running, what is displayed there is based off what action the user choise.
I had a conversion with a co-worker who was totally against this design because he thought that the VM's should not know about any views. He is right in that the MainWindowViewModel has a method called LoadView that accepts an enum containing the names of the content items to show.
So, if the user clicks a customer account, the click handler would pass AppViews.CustomerAccount to LoadView, and the LoadView method looks like this:
private UserControl _MainContent;
public UserControl MainContent
{
get { return _MainContent; }
set
{
if (_MainContent == value)
return;
_MainContent = value;
RaisePropertyChanged("MainContent");
}
}
public void LoadView(AppViews ViewToLoad)
{
_ViewModeBase vm = null;
UserControl view = null;
switch (ViewToLoad)
{
case AppViews.CustomerAccount:
vm = new CustomerAccountViewModel();
view = new CustomerAccountView();
break;
}
view.DataContext = vm;
MainContent = view;
}
Again, I have done this with success a few times, but I want to make sure it's a solid design.
Anyone have a better way?
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
If you really want to separate a bit more, use a DataTemplateSelector (ContentTemplateSelector property) to choose which view to display, instead of selecting it in LoadView. Instead of setting the DataContext on the View, bind the DataContext of the container to a VM property.
Either way, you'll have to use a bit of code-behind to select which view control to load... I mean, you could go through a LOT of effort to get all of that in the XAML, but in my opinion, it just isn't worth it.
|
|
|
|
|
Ok, but doesn't that require create a template for every view, instead of user controls. A user control would have its own ViewModel.
If it's not broken, fix it until it is
|
|
|
|
|
The template would, effectively, simply wrap the user control.
|
|
|
|
|
Ok, I'm not sure I understand.
A user control is its own file, correct? Whereas a template is defined in a resource dict?
What is the benefit of one over the other?
If it's not broken, fix it until it is
|
|
|
|
|
The user control would still be there as a discrete object (the View in other words). The data template would simply marry the view to a particular view model. If you look at Josh Smith's classic MVVM article[^], he demonstrates this neatly with:
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:vm="clr-namespace:DemoApp.ViewModel"
xmlns:vw="clr-namespace:DemoApp.View"
>
<DataTemplate DataType="{x:Type vm:AllCustomersViewModel}">
<vw:AllCustomersView />
</DataTemplate>
<DataTemplate DataType="{x:Type vm:CustomerViewModel}">
<vw:CustomerView />
</DataTemplate>
</ResourceDictionary>
|
|
|
|
|
Ok, I see. I'v read it, but I'll go back & re-read now.
So then which template is used is determined by some data, rather than by business logic?
If it's not broken, fix it until it is
|
|
|
|
|
I'm sort of there on this...
Can you show me how in the MainWindowViewModel this code is used? For example, if the user selects Show All Customers, how does the template above get used/loaded in the MainWindowViewModel?
I saw in his article where it says
"The MainWindowResources.xaml file has a ResourceDictionary. That dictionary is added to the main window's resource hierarchy, which means that the resources it contains are in the window's resource scope. When a tab item's content is set to a ViewModel object, a typed DataTemplate from this dictionary supplies a view (that is, a user control) to render it"
So the Content is set to a VM, not a View?
If it's not broken, fix it until it is
|
|
|
|
|
That's correct. The appropriate DataTemplate is picked because it matches the ViewModel. In other words, it looks at the DataType to pick up the appropriate DataTemplate.
|
|
|
|
|
Ah, right, forgot about just setting the DataTemplates based on VM type... Much cleaner than a DataTemplateSelector...
So, what Pete said 
|
|
|
|
|
Hey, you and me are in this WPF thing together bro. 
|
|
|
|
|
In it? Man, I'm up to my neck in it, and it's great 
Granted, I tend to stray from proper MVVM now and then, but I gotta say, WPF enables some nice-looking and stable interfaces... Never going back to WinForms
|
|
|
|
|
So I'm assuming that the VM is bound to the view automatically?
If it's not broken, fix it until it is
|
|
|
|
|
Ideally, you don't want to change the DataContext property from code. The usual method is to set the entire window to a ViewModel, and each section can have its DataContext bound to a property on that ViewModel.
MainWindow --> DataContext = MainWindowVIewModel
ContentFrame --> DataContext bound to ContentModel property (on MainWindowViewModel)
HelpFrame --> DataContext bound to HelpModel property (on MainWindowViewModel)
That way, when you change the content, all you do is change, in this example, the ContentModel property. Since the GUI control is hooked up with databinding, it'll automatically grab the new data, and switch to the proper DataTemplate.
So in short, you want to set the uppermost DataContext property once on window load, then operate exclusively through ViewModel properties.
|
|
|
|
|
I understand that, but Pete pointed me to this[^], and I'm wondering where or how in this design is the data context set?
So, if the content area is defined like this
<ContentPresenter x:Name="MainContent"
Grid.Row="2"
Grid.Column="0"
Content="{Binding MainContent}" />
In the MainWindowViewModel I would then set the MainContent property to the MainContentViewModel. How does the MainContentViewModel.DataContext get set. It won't know about the MainWindowViewModel.
Unless I'm missing something?
If it's not broken, fix it until it is
|
|
|
|
|
DataContext is inherited, so when the window itself is created, set its DataContext to a root ViewModel class. Then when you use the code you just posted, it would bind to the "MainContent" property of that ViewModel, which would be your MainContentViewModel (Or whatever you decide to call it).
The initial DataContext property for the window is set in code... After that, everything is data-bound.
|
|
|
|
|
Got it! Thanks
If it's not broken, fix it until it is
|
|
|
|
|
No problem, man. Glad we could help
|
|
|
|
|
|
My office has gone 100% thin client [ VMWare ], the exception being we developers. I'm not well versed in the official descriptive terms used, but it is of the type of environment where each user has an image stored on a server, initially identical, but with a fixed storage space available to them.
One problem is that a number of my applications, when moved to the TC, do not function correctly. This has various causes - different version of Windows applications which break my references or a local dedicated impact printer that required a local driver.
I'm requesting that I be given an instance that is non-volatile (i.e., I can customize by installing compilers, &etc. that won't be destroyed on the next refresh). Then I was asked the following:
- Are there specialized compilers and/or techniques that should be used when coding for this type of TC environment?
- Related to this is the question of a the feasibility/sense of a single copy (rather than clones in each workspace) being a possible development target?
In light of the above (bolded) questions, I'm hoping for some answers, best-practices, and references.
Thanks, in advance
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
modified 19-Jun-12 12:38pm.
|
|
|
|
|
May I ask what they define as a thin client? AFAIK, a tablet-pc would qualify as a "thin" client - Windows OTOH is a "rich" client. No, you don't need a special compiler to run software in a VM that's running Windows.
W∴ Balboos wrote: Related to this is the question of a the feasibility/sense of a single copy (rather than clones in each workspace) being a possible development target?
A single copy means that you only have to maintain a single point. Having clones means that you'll also need to update the clones.
Bastard Programmer from Hell 
|
|
|
|
|
I thought the reference to VMWare in the first line delineated the type of thin client.
Your particular division doesn't seem to fit: the user's have small boxes on their desktops which connect them to our network; they run a local instance of Win-XP (downloaded from their space on the server), along with various applications that run under Win-XP . So, running individual Windows in VMs, resident upon a remote server: rich or thin? If a table PC runs stand-alone, how could that qualify as a thin client?
Perhaps better phrased: I know that the applications developed for Win-XP and Visual Studio will work in the TC environment: my argument to management is that I should be developing in the environment in which the apps will run in order to be sure they actually do run (an environment that won't be wiped out every time the user instances get a general reset). One of the managers then wondered if there is, perhaps, specialization to working within this TC environment (ergo, special tools) rather than considering that, virtual though it may be, it may be treated as if programming for a standard desktop.
A single copy vs. individual copies for each user: maintenance is not an issue as they can update them all at a stroke in either case. There could conceptually be a difference in application builds, libraries, &etc., for the single-copy version as, at the least, it must take care of any number of active threads.
As my understanding of the server world is limited, perhaps I am missed something in your response.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: So, running individual Windows in VMs, resident upon a remote server: rich or thin? If a table PC runs stand-alone, how could that qualify as a thin client?
Let's skip the argument that I caused, it's not going to help much.
W∴ Balboos wrote: I know that the applications developed for Win-XP and Visual Studio will work in the TC environment: my argument to management is that I should be developing in the environment in which the apps will run in order to be sure they actually do run (an environment that won't be wiped out every time the user instances get a general reset). One of the managers then wondered if there is, perhaps, specialization to working within this TC environment (ergo, special tools) rather than considering that, virtual though it may be, it may be treated as if programming for a standard desktop.
Such tool would need to "save" any changes made to the system, otherwise it would still help much. I don't know of a tool that does that; cloning is usually an all-or-nothing deal, and the only facility that I have seen used Citrix to "deploy" their app to the clones.
FWIW; Windows NT supports symbolic links[^], and you could have some directories in the clone "point" to writable places.
Bastard Programmer from Hell
|
|
|
|
|
The arguments were mostly out of my ignorance about a field newly sprung upon me - leaning the correct descriptions will prevent me from confusing the issues certain to appear in the future.
The all-or-nothing thing is where the (main) problem lies - even if I load the compiler and backup my source, the registry will be trashed (from my point of view) every time they refresh from their image.
Following your link, I looked up the symbolic link idea. It would seem to be feasible, recreate them whenever the system's refreshed, pointing to a non-volatile work area - but it still seems that the registry, now lacking all references to the applications in their non-volatile home, would leave me with an unworkable system.
Still - thanks. It's somewhere to begin. Really, they need to not refresh the developer VM's.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Some time ago I used a tool to create/compare registry-snapshots. You could use that tool to identify which changes are made to the registry. You could save a description of those changes in a database on a remote server, and import them into the local registry when your app starts.
That would create a lot of extra work, but that way you wouldn't have to worry about registry-settings from third-party components.
W∴ Balboos wrote: Really, they need to not refresh the developer VM's
The argument would be that it keeps the cost down of keeping your system up. I'd have a hard time if I couldn't install a supporting tool on demand.
Bastard Programmer from Hell
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
