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
Related
I have a view which has 2 controls on it. They all use the same viewmodel, but if controlA makes a change to the view model, then I want controlB and the view to be able to see the change that has been made. My first thought about how to do this is to make the viewmodel a singleton, but I can't work out how to do this. Any suggestions either for making the view model a singleton or for a different way to achieve the same result?
Thanks.
I've been struggling with the right way to design a Rails model/controller for a dashboard/portal that can support easy/clean widget development. I've already (as a diversion) wrote a jQuery/jQuery-UI/CSS basic view that has worked out the column/order HTML and controls to reorder/minimize/remove the widgets, and now I'm coming back to how best to design the model and controller.
As a central place to find all widget information, I have a Widget model. (as a non-ActiveRecord for now) Ideally I'd like to have the Widget Index view simply take the Widgets from the Controller, and the model would contain widget attributes needed to render the view. This would include widget "partial" and "controller" attributes that the view could use to render a specific widget's partial view in my Dashboard view.
I don't want to have to overload my Widget controller with a bunch of potential widget specific data that their partial view might use. Instead I want to have the partial render itself, by just specifying the widget's partial and controller to use. Then the partial view and controller can do whatever they need to for that widget.
Widget Controller Index --> render #widgets --> widget1 widdget1_controller/partial view1
\ \-> widget2 widdget2_controller/partial view2
\--> widget3 widdget3_controller/partial view3
The Dashboard model would contain column, order, partial view, controller.
The Widget specific partial Views and Controllers would would located under a sub-folder of the controllers and views/widget folders to keep things clean.
I'm hoping this will help when trying to add AJAX support. Each widget controller can handle their own Controller Actions (like editing the widget or saving something) and I can have the client browser make AJAX calls to the partial for updated information without having to call the original Widget Controller, etc...
What do you guys think? Do you have a better suggestion?
This might be to late now, but there is an extension on cells called Apotomo, which basically extends cells with actions and ajax to make little widgets. It's pretty awesome, and they have tutorials on doing the whole widget thing you're talking about. If this is to late, I would guess it would be pretty easy to port your cells code over to the widgets as they're very similar.
I think Cells is what you looking for.
Simple question here... Is it alright in terms of MVC design to observe a value in the model from a view (using Key-Value observing), and update the view's current location on the screen based on when the model's variable changes?
Is it okay to observe from the view object and have that object move itself when the Location variable inside of the model object changes?
Or is this against MVC because the view and the model are communicating in a sense?
You should tie it through a C, controller, item. Even if it means you're pulling in the state data from the model, and then having the controller set the view or the view read that data from the Controller.
The view and model should always be separated by a controller. That's MVC according to Apple. The reason is that even right now it may be straightforward for you to have the view reference the model's state - but the model could change in the future, and then you'd be stuck updating the view, when there's really no reason the view should be impacted. And the model should never update the view's position - it should really not have any idea of any details of display. That's the job of a controller, to control your views and move them around based on model data.
Think about it this way: the view should only know how to display things or interact with user I/O, a model should only know about the business logic with data that comes in over an interface of inputs and outputs. You should be able to run a model without a view even existing, instead you should be able to just have unit test type code that feeds those inputs and outputs. So something like moving a view around is completely out of the responsibilities of a model.
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.
I have some UI elements that will share common parts with other UI elements. They correspond to model objects in an inheritance hierarchy.
As an example let's say all Layers can be toggled on/off. All WaveLayers are Layers which additionally define a .wav filename. And there is a specific concrete subclass of WaveLayer called GroovyLayer which requires additional parameters.
Visually I'd like to have a long panel where the top section holds the general Layer UI, the next section holds the WaveLayer-specific UI, and the last section holds the GroovyLayer-specific UI. There may be like 10 or so concrete subclasses, each which share the same top sections corresponding to Layer and WaveLayer.
How should I set this up in InterfaceBuilder? Do I start at the top (with a placeholder for the subclass stuff) or at the bottom (with placeholders for the parent classes' stuff)? How should I go about setting up these placeholders in InterfaceBuilder and substituting in the right NSViews at the right times?
I've got this sort of thing to work by using a blank "custom view" in IB and tying it to an outlet in my controller class, and then substituting that view with another view tied to my controller from elsewhere in another NIB, but that seems unelegant, as my controller then carries both "old view" and "new view" members...
Lay out the views however you wish. Then select the custom view that represents your subclass and set its class name in the inspector.
As to whether to load the views from separate xib files, I think that's overkill here. From your description these views are always visible together, so you gain nothing but complexity loading them from individual files.
The trick you seemed to be missing was setting the class name of the custom view to that of your subclass.