I have "alternative" xaml views for a viewmodel and I am currently using a technique where I set the style property on the view (containing a control template) and would like to know what is the best/preferred Caliburn technique to re-invoke conventions, bindings, etc., that are setup initially by Caliburn when showing the viewmodel.
I am using a View-Model-First approach, so possibly I am using the wrong technique and should be looking at a way (e.g. View contexts) to have the Viewmodel instigate the change?
Thanks
<ContentControl cm:View.Context="{Binding CurrentView, Mode=TwoWay}" cm:View.Model="{Binding}" />
Multiple views over 1 viewmodel technique. Then the folder structure would be slightly different to help organize but namespace is how view is found to place into the contentcontrol content. I use this in multiple projects
Viewmodel logic facilitates the view "switching".
Related
I have an abstract base view model (IBaseViewModel) and two classes that implement it (Base1ViewModel, Base2ViewModel). I also have a Xaml user control, and I want in one page to use Base1ViewModel as view model and in another page Base2ViewModel as view model.
Prism best practice is to bind to view model by name, so what I ended up doing is duplicating the xaml file into Base1View and Base2View so each view gets the right view model, but this is obviously not ideal because then changes to the xaml should be duplicated as well.
Is there a solution/design in which I can reuse the same xaml user control with two different view models?
Thanks,
Noam
In the past I have mainly created command-line programs, however I have recently started to venture into the world of GUI's and objective-c. I am trying to design an UI that has a repetitive structure of the same objects containing different data, and am uncertain as to the best way to create such a repetitive user interface.
For example, if you look at the Month View of Calendar.app, the interface is very repetitive. It is essentially a 7x6 grid of the same view (i.e. each day). My question is what would be the best way to go about creating such a repetitive view?
I initially saw two options:
Create the entire grid in the interface builder explicitly. But I see this as being rather cumbersome and presenting a load of hassle in controlling the individual objects later in code.
Creating a custom view for the grid, which is then programmatically populated by a series of 'day' custom views. I.e. create 42 instances of the same 'day' View within the custom view to form the grid.
In the case of the second I thought an array of DayView View Controllers may provide the solution but wasn't able to get very far with this solution.
Is one of these options the best way to go about achieving this task, or is there a better way? And how would one go about creating this?
UITableView and UICollectionView are great views to display this "repetitive" ui you call. These repetitive views are cells that are presented into sections (in a table view). I suggest you search for documentation about these classes.
Table view programming guide:
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TableView_iPhone/TableViewStyles/TableViewCharacteristics.html#//apple_ref/doc/uid/TP40007451
UICollectionView class reference:
https://developer.apple.com/library/ios/documentation/uikit/reference/UICollectionView_class/Reference/Reference.html
I am trying to get my head around MVVM and the Navigation-based project template in SL4. At the moment I am trying to move the ContentFrame_Navigated event handler into the ViewModel. Basically this event handler checks each hyperlink button in the menu bar against the current page and adjusts the style accordingly. To do this it seems I need to pass the EventArgs as well as another object. I see MVVM Light has the PassEventArgsToCommand bit, but what about passing another object/control? In this case it's the StackPanel hosting the list of menu item hyperlinks. I'm just getting my head around the MVVM concept, what's the best practice in this case?
Cheers,
Dany.
With MVVM you have to think more abstract. You are not daling with a list of HyperLink elements, but with a list of Navigation Targets. I.e. you should separate the presentation (HyperLink elemen) from the data (the URL, the Title, whether the item is selected or not, etc.). You now hold the data in a list on your ViewModel (normally you would see this data as the ViewModel of your Hyperlinks, and name it accordingly). The items are held in a ObservableCollection so that you can track changes if a item is added etc.
To display this list you can use a class inheriting from ItemsPresnter (e.g. a ListBox) and use binding to set the properties. Now you navigate to a page you can set the IsSelected property of the relevant item in the list, resetting all other IsSelected properties.
As the navigation targets can be seen as a global collection, you can also hold it in a property on the ViewLocator, so that all Views and ViewModel can access this list, and setting the IsSelectedProperty is applicable to all Views. This global collection represent you navigation state.
And, BTW, the EventToCommand, the RelayCommand, and the Command attribute ony support one parameter. Furthermore, from experience I can advise you that it is not good practice (although you obviously can do it) to mix View objects, such as EventArgs, or elements and your ViewModel.
one solution is to put the menu items the ViewModel, and the View can bind this list.
then the View wouldn't need to send the menu items to the ViewModel
I am making a UIView-based class for use as a tableHeaderView. It will have several controls that will be based on edit mode - some will appear/disappear and some will change appearance when it switches modes. The height of the view itself will change when it switches modes. Seeing that the layout will change a lot, I decided it would be better to just make the whole thing programmatically than to try to lay it out in a nib.
What I am struggling with is where the view/controller separation should be. Should the viewcontroller have an object for each control (UITextField, UISegmentedControl, UIButton, etc) or should it just have an instance of my UIView-based class?
Where should the code that actually creates the controls and sets the properties reside? Should my view have a method that gets called to set the entire view (based on edit mode) or does this put too much power in the view that should be in the controller? Should the view only set the positions of the controls? Or should there not even be a UIView-based class - the view controller will declare and configure all the controls by itself?
What is the proper MVC separation here?
jorj
The MVC rule of thumb is that your controller is the go-between – if your model is storing information about the edit mode, then your code will be cleaner if the controller does the work. If the edit mode settings are discarded when the view goes away, then the controller doesn't need to know about them.
It's also worth considering whether this code will be re-used – if you're creating a view that you're going to use again elsewhere, that may make it easier to decide where the "brains" of the code should reside.
Can I have multiple ViewModel for a View in WPF? Because some times we need to show the view only in simple view format and sometimes the same view has to shown in editable format. Hence we can create seperate view models for each.
So is there any way to hook 2 diffrent view models to a view?
A ViewModel should serve as the Data Context for your View, so that would only allow a single VM.
There is no reason why you could not break you View up in to multiple UserControls, each with their own ViewModel.
Generally you're going to bind your View to a single type of View Model. That's not to say that your type couldn't be an interface, or a base class from which both of your views inherit.
I tend to only use an interface or base/derived class situation when I have a single view model type that is going to span several different views. For example if I have two different types of forms that display widget information, I would create a single base Widget ViewModel class.
In your case, it sounds you should either a.) create two views for your simple and advanced views or b.) simply use a single ViewModel class.