I have an application that uses MEF and Caliburn.Micro. The main view has canvas and a button. The button when clicked, should create a new widget and display it in the canvas. The widget in this case is a UserControl that has a view and viewmodel.
The user can add 0-N of these widgets to the canvas.
I have the widget in the MEF catalog but I can't seem to find an example of how to wire it up in Caliburn.Micro.
Any ideas what I'd write in the main view model when that button is pressed?
You should have a collection of view models that your Canvas binds to. In fact, if you use a Conductor collection type in Caliburn.Micro (have a look at Conductor<T>.Collection.AllActive), then it already has an Items collection.
When the button is clicked, your main view model verb (method) can add a new view model to the Items collection. Your main view model will therefore need a view model factory injected in order to create these child view models.
Related
I am developing an app where I have create, display and change views.
I want to share the screen between these views, but I thought embedding the whole screen as a fragment is not advisable because fragments are for small reusable pieces.
However, embedding the screen as a view means I have to specify a controller, but I want to use the parent view's controller, as that implements the logic of the create/display/change action. (The views have some shared functions in a library file).
Is there a way that I can embed a view but still use the parent view's controller, or should I embed the screen as a fragment?
I am currently working with Swift and I was learning about MVC - one question that popped out was this: I am trying to implement a WKWebView - and I already know how to do this within a ViewController.
My question is: should I create my own WebView class to place the WKWebView or should I only house it with in the ViewController? I am trying to follow the MVC structure.
It's a web view, so it should be placed in the view controller in the storyboard. This really has nothing to do with MVC, per se.
The view controller is your Controller.
The view controller's root view and the web view you're putting in it are the View.
The Model may or may not be relevant here since a model is usually just a data structure that the Controller uses to populate the View. It could just be the HTML that you pass to the web view.
My question is: should I create my own WebView class to place the WKWebView or should I only house it within the ViewController? I am trying to follow the MVC structure.
The view in Model View Controller really refers to a view and its entire graph of subviews. If a WKWebView instance is the view that contains everything that the controller will manage, then it's fine to make that "the" view; there's no need to put it inside another view just for the sake of containing it. On the other hand, if you want the same controller to manage other views not contained in the web view, then you can put the web view and the others all inside some other view and let the controller manage that.
How you organize your views really isn't determined by MVC -- just do what works. MVC really speaks to the way that the information your app operates on is owned and managed by a model, displayed in a view, and how the interactions between model and view are mediated by the controller.
My GWT app will have 4 - 5 different views but each one will have 2 similar buttons on the bottom of the view. The function of these buttons will vary between each view but their appeararnce/position will remain the same. Is there any design strategy that I could apply in this case? Could I go down the road of having a base panel class that adds the buttons and each extending class then implements the different functionality or is there a better way to do it?
Create a composite widget BottomToolbar consisting of a panel with two buttons. Add two methods to this widget: setLeftButtonHandler(ClickHandler handler) and setRightButtonHandler(ClickHandler handler).
When you add this widget to the view, your Controller/Activity/Presenter (whatever you use) only needs to set these handlers.
The best to do is to create one view that takes a controller which is different for your 4 or 5 views.
This is a basic MVC pattern : your view can be instanced several times but user can interact differently depending on the controller you give to the view.
Then, you can also extends your main view to provide more ui differences.
I have two ListViews (in separate views). These views are bound to separate view-models but the ListViews contain the same entity type. Both views allow the user to select an item and navigate to it's detail/edit view.
What do I need to do to share this detail view between the two list views?
Here is what I have tried:
Assign the selected item to a property in the detail view's view-model
This initially appeared to work but actually breaks Kendo MVVM. Since the item is in the list view's view-model, assigning it to a property in another view-model causes problems.
Refresh data in each view's show event
While this almost works, it has a couple problems. 1) Getting fresh data all the time can be slow. 2) When saving changes in the detail view and navigating back to the list view, the save is async, so there is no guarantee that those changes will have been persisted before the call for ListView data. This also negates one of the benefits of MVVM and observables.
Share the view-model across views
The examples I have seen that have a list and detail view, have both views sharing a view-model with a selectedItem property. This is not possible in my particular case because I have two list views that navigate to the same detail view - not to mention that I prefer to have a separate view-model for each view so that the view-models don't become a huge mess. Am I supposed to have all views share a single view-model?
What am I missing?
Maybe you could extract the observable model to a plain object model with the toJSON() method, and then create a new observable model from it by wrapping it again. This should clear the existing bindings and avoids the conflicts you've found in your first approach.
var model = kendo.observable( otherModel.toJSON() );
I'm using WPF and trying to program the MVVM way.
I understand how every view has its own view model and this works quite well. I am struggling to manage the interaction between views though.
Say I have two views, View1 and View2, each with its own ViewModel, ViewModel1 and ViewModel2. If I have a combobox on View1 and a button, what is the correct way to close the first view, notify the second view of the selection and show the second view once the button is pressed? It doesn't seem like it should go in the model because it's a UI thing. The ViewModel shouldn't know how to open and close WPF forms (or should it?) And the views shouldn't know about any other ViewModels (or should they?)
So how are these problems solved? In a nutshell:
1) How is data passed between views?
2) What manages the lifetime/visibility of views?
It will depend on whether you are doing view model or view first, and the exact implementation details will depend on if you are using an MVVM framework. If you aren't using a framework, then I would strongly recommend you start using one.
In your example, when the button is pressed, a method on ViewModel1 will be invoked. If doing view model first (which I would recommend), you would instantiate an instance of ViewModel2, and at this point you could pass in the combobox selection to the constructor of ViewModel2.
Depending on your framework, there will be different ways of then displaying the view associated with ViewModel2.
For 1) you can sychronize data through the DataModel. Provided each view shares the same instance of the DataModel and it implements INotifyPropertyChanged multiple views can be updated simulateneously.
Your sesond question is a matter of design, as #devdigital states it can depend on whether it is View first or ViewModel first. I would consider the introduction of a Controller class in much as the same way ASP.Net MVC works which controls which view is displayed. You can expose a ViewClosed event on the ViewModel which the controller can listen to and based on your workflow open another view.
You might consider introducing Controllers which are responsible for the lifetime management of the ViewModels. Furthermore, they mediate between the ViewModels.
The sample applications of the WPF Application Framework (WAF) show how these Controllers can be implemented.