do you think is a good practise to create a UserControl already with a ViewModel and deploy both together? This way the UserControl will be binded to the ViewModel from stock.
Looks as a good idea to me but I never saw such a thing.
Thanks.
The one thing you should be careful of with this approach is that you want to keep your datacontext open and available for binding to in controls where you are using this control.
If you block the data context it'll make it so any bindings you do to the control later will have to have a source specified.
I personally see nothing bad in this idea. For a sufficiently complex UserControl, a ViewModel is anyway needed. I would however make it (VM) as extensible as possible.
Indeed, I've seen some VMs shipped together with controls -- in Swing (Java). For example, TableModel serves indeed as a kind of VM for JTable. [But without real bindings Swing's VMs are quite weak.]
Related
I am new to WPF having previously worked with WinForms on occasion and I still trying to get my head around the WPF mentality, which given my background is embedded coding, seems quite removed.
In my project I need to create a Grid Panel "template", which I'll call "Fred" (where in this case Fred is simply a cluster of graphically customized buttons) and spawn multiple instances of this to the UI programmatically based on external events. I am finding it hard to see an obvious way to do this (perhaps that is because there maybe multiple ways?) and have looked into ControlTemplates, Styles and Custom Elements. I suspect the solution lies in the latter but I am also concerned I might be thinking about this in the wrong way. To me it seems to make sense to visualize Fred as a Grid resource that I can programmatically invoke somehow when I need to create a new instance, but given I found it hard to "google" this very thing then perhaps I am going about this all wrong?
I apologies if this is a bit vague.
My question here is two fold:
Is this a sensible way to achieve my end goal i.e. if I need to programmatically spawn this cluster of customized Buttons (Fred) then does it make sense to contain these in a Grid that can be accessed by the main C# or is there a more standard way that I am missing to achieve this?
Depending on the answer to (1) are there code examples to achieve this?
The concept you are looking for is an "ItemsControl" (which is itself a usable class, and also has several derived classes like ListView and ListBox) in combination with DataTemplates.
In this case you would make "Fred" a DataTemplate (commonly as the direct descendant of your ItemControls ItemTemplate property in XAML). You then bind ItemsSource to a collection (should be ObservableCollection<T> for runtime additions/deletions).
All of this relies on using the MVVM pattern (which coming from WinForms you probably aren't). I would suggest looking at MSDN, Stack Overflow, an excellent blog series by Reed Copsey: http://reedcopsey.com/series/windows-forms-to-mvvm/ or just google "WPF and MVVM" to learn more.
To answer your questions explicitly:
Yes; you have the right concept but are thinking about it in WinForms terms/practices. Use MVVM instead.
Yes; there are many resources available.
I'm using PRISM and MVVM in my modular Silverlight application. I'm still trying to figure out PROPER way to do interactions in MVVM fashion and 2 methods that PRISM and samples offer is not something I like for different reasons.
Method 1(PRISM): To use different region adapter. Basically, it involves attached properties on container and injecting view into region. This works almost 100% but negative of this method is that there is no good way to communicate results back. I can use EventAggregator but something doesn't feel right to raise event with data when interaction completed.
Method 2(PRISM): To use InteractionRequest. That involves trigger action and some big boilerplate XAML that I have to repeat on each view.
I'm thinking on creating something on my own which would require creating my own control which will have to be added to each view but with very little XAML and some kind of IPopupService that I can bind this control to. I can pass all needed data via PopupService but in order to actually make action of POPUP happen - I need to call method on this control and that falls apart in MVVM
I wonder how to call method on control in MVVM where view shouldn't be aware of VM ?
View has no option but be aware of VM, since it binds to it.
You could define some kind of a service indeed with a run-time implementation that would interact with the UI and design/test/debug implementation that does something else. You might also publish some events in your VM layer that the View layer would decide how to interpret.
First off, I don't think MVVM is a good choice if you are developing a UserControl that will be consumed by others. A lookless control is what you really should be developing. Jeremiah Morrill has a blog post about this subject.
With that said, you can set the datacontext with XAML if you have a default public constructor.
Inside ControlView.xaml put:
<UserControl.DataContext>
<local:ControlViewModel />
</UserControl.DataContext>
Recently i got explained that MVVM can only be done "the right way" if i use DataTemplates. Is this truely the case?
I'd say its a good idea to use DataTemplates if you want highly reusable "Views".
But if i am going to develop an application that has, say, five to ten different pages, and there is very little to none reuse of specific controls (like the "Person" view is only used once, and its highly likely that this requirement doenst change), why cant i simply create a usercontrol and put that directly into the code?
Am i missing some important core principle of MVVM here?
Main selling point of MVVM is separation of View from the ViewModel (so that VM doesnt know about View) by using powerful Binding feature of WPF.
DataTemplates are a just another feature which allows you to represent data in different way. As you have said, if you dont have reusable DataTemplate then dont create one, even if you do make sure it resides in the View's Resources, you can share it wider group if you wanted do.
using UserControl can be useful where you need to do something extra (apart from simple representing data), for example, some complex validation or extra commands/buttons
I dont think MVVM and DataTemplates are related in the same context.
There is no special needing for DataTemplate, you have a view and a viewmodel that cooperates with databindings and events. The MVVM goal in WPF is to remove the code from the view to achieve a real presentation only view, and not a messy code behind store. Having the ViewModel agnostic from the view is another goal, even if not always achieved.
I want to create two diffent types of DockPanels. If the user clicks on one link, it loads DockPanel #1 otherwise it loads #2.
Can we dynamically swap them? I'm new to WPF. In REALBasic, I'd use GroupPanels and I'd swap them if needed.
Thanks
U can dynamicly create controls and fill their content with other controls. Or u can just place both types and hide one u dont want to show.
Take a look at Josh Smith's MVVM Article in MSDN Magazine. Josh is considered by many to be The MVVM Guru, and this article does a good job at explaining the basics.
With that in mind, I would probably do your app as an MVVM application.
The Model would "just" be your data model (much like in MVC).
Next there would be a View for each of your panels. Each View could either be set up as a DataTemplate (like in the article), or as a UserControl (as I've done and seen done many other places as well). Doing so makes it modular, and easier to expand, maintain, etc.
Your MainWindow is really also considered a View, onto which you place other Views.
All of the Views will be controlled by one or more ViewModel classes. How many you have depends on your design. Generally, if there is distinct functionality, you will have a more-or-less one-to-one relationship between a View and a ViewModel (although you can certainly share multiple Views with a single ViewModel). There will also generally be a single "Main ViewModel" class to hold everything together.
In general terms given the general description of your problem, it is likely that your ViewModel will contain a Command (or Commands), handled when your user chooses a link. This Command will likely set some property, which will control which View gets shown (usually via Binding).
Sorry I can't get more detailed than this, but if I did I'd need to know more about your design, and I'd have to write a lot more stuff, which isn't really appropriate in this forum.
I'm starting to develop a WP7 app with MVVM Light. I want to make use of the pivot control to show two different lists of different item types. Would it be best practice to create the PivotItems as UserControls or should I stick everything in one viewmodel?
I think there is no "correct" way to do it, it just depends on your vision.
Personnally, I always create separate UserControls to act as PivotItems.
The main objective is to make my code clearer, with more separate classes it is way more easily unserstandable!
However it also depends on the complexity of the items. Don't feel forced to create one UserControl per item, just separate if the control is quite complex and requires quite a lot of XAML lines, it will clarify your code