I'm currently using RobotLegs with the Presentation Model pattern to develop a Flex 4 project. I understand that all business logic related to a View resides in the Presentation Model associated with that view, however, I am confused when it comes to View specific logic.
For example, I have an indicator that needs to be positioned relatively to list items depending on which list item is selected. Is it acceptable in the Presentation pattern to put the logic that will position the indicator in the View and simply have that logic run in reaction to a selectedIndex property changing in the presentation model?
The reason I am considering this is that since the Presentation Model does not have a reference to the view it is difficult to come up with an ideal solution for manipulating view components.
Ask yourself this: if you had to use the same Presentation Model with a view that looked different (for instance, a mobile View), would you still need to handle this, and could you abstract it enough to handle it the same way from the PM?
It sounds to me like you're moving the indicator relative to the itemRenderer, which suggests that you may want to have some sort of reference to the renderer or its coordinates in the PM (var indicatorIsRelativeTo:InteractiveObject or var indicatorIsRelativeTo:Rect). You may even want to have another variable that describes how it is relative to that object (above, below, left, right).
Related
I see references to "best practice", but why is it better to use a ViewBag object versus an Application object when accessing static data in the view?
Both are possible. Suppose you want to add an object to every view but not necessarily pass it to view the model (since there may not even be a model for a given view)?
This could be done several ways, like with a global filter, but accessing an application variable is much more convenient.
Both are nasty workarounds that bypass everything that MVC stands for.
In the Model-View-Controller pattern, your Controller prepares a Model containing all values necessary to populate the View, and the View in turn displays the Model properties the way it's intended to.
Any way you use to circumvent that pattern, like ViewBag, Session or Application variables, are anti-patterns that defeat the MVC way - as long as you access those variables directly from the View.
See also Pass data to layout that are common to all pages and Create ViewModel for Navigation: if you need certain values on all pages, consider using a base viewmodel or partial views.
And yes, this discussion borders on pragmatic/purist. If you for example have a menu that's the same for every user, but which is loaded from a database, then sure, go ahead and store it in an Application variable for caching purposes to load it once per AppDomain. But then still use a base ViewModel or Partial to render that menu.
I wouldn't say putting data in a view bag is a best practice. I would say using a view model is a best practice.
Suppose you want to add object to every view but not necessarily pass
it to view the model (since there may not even be a model for a given
view).
Even if you haven't define a view model, conceptually there is a model is you are passing data to the view.
See Why do we use ViewModels?
If the data is on every view, you could create a base view model that every model inherits from that contains the universal data.
you could also create a partial view with its own view model that is then applied to each page.
Normally I design ViewModels taking in consideration the business or functional concepts of the application.
For example, if you are displaying an invoice, the view model should contain all the properties related to invoices that needs to be displayed on that specific view. I wouldn't use ViewBags/ViewData for this purposes.
On the ViewBag I normally put other and "more ancillary" properties like, for example, a boolean for showing/hiding some part of the view, or maybe for some other "not business relevant" properties.
Of course some people could disagree with this and would put everything on the Viewmodels, some others not. This is a decision you must take at the beginning so you can be consistent in the way you design across the application.
I am visualizing multiple steps of a simulation and exporting them as a movie. Since the geometry is complicated, I would like to show it from several perspectives side-by-side, with the same pipeline.
Paraview has "Render View (Comparative)" which lets me do just that, but it resets the pipeline for each new comparative view. Since the pipeline is complex, I have to set it up manually for each new view, which is tedious, and changes to one don't change the other.
Am I overlooking a simple way to just show exactly the same thing, just from different point, in the comparative render view?
You can open a new view in the same layout (http://www.paraview.org/Wiki/Beginning_GUI#Split_windows) , and when you make a video you will record both because they are in the same layout.
Still, they will not be synchronized (to change the visibility of an object, you will have to do it in each view), maybe for automating this the python tracing can help.
I have a Qt C++ application that uses several different models (ultimately) based on QAbstractItemModel.
Several of the items in these models use a custom Delegate to render them properly, these work well.
However, I'm not sure how best to specify which of these Delegate classes should be used to render the data.
At present, I'm calling QAbstractItemView::setItemDelegateForColumn() in each of the forms that contain a view.
This feels very clumsy, because it relies on the form classes knowing which delegate should be used for each column in every model - and if that changes in the future, I have to update every form.
Furthermore, in some cases a View is switching between two different models that require different Delegates, so for these the form class has to handle that switch as well.
Is there a better way to do this?
The model must not know about representation, so you should deal with the view. You can subclass involved view class (e.g. QTableView) and reimplement setModel virtual method. In your implementation call the parent class implementation and adjust item delegates based on specified model. Put objects of this class inside all your forms. So forms will not know about delegates. I think this approach agrees with the Model-View conception.
AFAIK, there's no better way.
However, instead of updating manually every form, i used to have an enum which holds the columns index, which is used both in the model and in the view to retrieve data and apply delegates.
I ask myself how do I create a view model correctly.
For instance, I have an edit view with some text boxes and a dropdownlist.
Should I separate the dropdown list into a new view model or shoud the edit view have one viewmodel with a list for the dropdownlist?
Or generally speaking, should I separate special input fields in separate view models?
When should a view have more than one view model and when not?
There's no clear rule of how to create and organize your view models correctly. Your question is too vague to be answered because you provided too little context.
I usually group view models according to functional blocks/parts of the screen they represent. So for example imagine that you have a complex form composed of multiple sections/fieldsets like contact details, delivery address, billing information, etc... An address could be composed of street, zip, city and country dropdown. I would create an address view model containing those four properties so that it can be reused in multiple views/partial views. This will also make validation easier as dependent properties will be packed into the same view model like validate for example that the given zip corresponds to the city and that the city belongs to the selected country.
For instance, I have an edit view with
some text boxes and a dropdownlist.
Should I separate the dropdown list
into a new view model or shoud the
edit view have one viewmodel with a
list for the dropdownlist?
I would say no, if those fields are somehow functionally related.
Conclusion: you will have to find the right balance between having a view model per field on the screen and having a single view model per application.
I prefer the approach of one view model per view/partial view. This is in my opinion the best approach if you believe the view model's single purpose should be modeling the view. This paradigm also supports the use of strongly typed views thus providing compile time error checking for your views model binding and you get the added benefit of intellisense. In the scenarios where you want to re-use some logic, I find it can often be satisfied by re-factoring the view into partial views and providing these partials with their own view models. It should be emphasized that no domain logic should exists in your view models as it really belongs in a domain model.
You should separate the dropdown list into new view model if you want to be reusable.
You would generally want to use ViewModel pattern if you want to store the data used by the typed view. For UI specific logic and details, a ViewHelper pattern would be more suited.
For some discussion on ViewModel see this article. http://theminimalistdeveloper.com/2010/08/21/why-when-and-how-to-use-typed-views-and-viewmodel-pattern-in-asp-net-mvc/
I was wondering best practices for views of inherited classes in PureMVC in this situation:
Multiple classes inherit a BaseClass (lets say InheritedClass1 and InheritedClass2)
Each InheritedClass has a respective view (derived from a base view class, but each unique)
With a given dataset (lets say ArrayCollection of InheritedClass1/2 Objects), the respective views need to be dynamically loaded.
The dataset is relatively large, so a TileList would be nice (since it only instantiates objects which are currently displayed)
I can think of a couple solutions, but I find them to be too "hackish" to be the best solution:
In View: Repeater over a BaseClassView which attributes a view to a State (set to the "InheritedClass1" state to add a InheritedClass1 object)
Pros: No unneeded memory increase (States' objects are instantiated when needed)
Cons: View is dependent on the data types, so adds coupling
In Mediator: Loop over the ArrayCollection and addChild() the views based on data type
Pros: Works.
Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View. Slower than a Repeater.
Any comments or other suggestions would be appreciated. Thanks!
The answer is simple if you like the first example. Why not have a map (Object()) on the mediator that assigns datatype to view component (or states). e.g.:
private static var map:Object = {"ic_oneType": "ic_oneState",
"ic_twoType": "ic_twoState"}
And the mediator can assign that map to the BaseClassView.
I'm likely to agree with the idea that you need some form of viewProxy that renders all your inherited views based on data fed to it from the mediator (e.g., first example). Can confirm or deny whether states is the best course of action in your UI though without more concrete examples.
Mediators are part of the View. How would you separate them from the View is beyond me.
I'd got with option 2.
Here's a topic from the pureMVC forum: Dynamically adding View components: where should I do it?.
The post by "pureMVC" should be of interest to you.
Also, the size of the dataset can be problematic. If it's really large you should consider using a List with renderers instead of adding a component for each item (repeaters do that). Which would further complicate things a bit because you'll have to wrap your data to keep the main component decoupled of the Model.
Cons: View is dependent on the data
types, so adds coupling
Typically, a view component has no other purpose than to display the domain data and possibly allow the user to interact with it. It is a given that the view component will need to have some understanding of the domain data.
So feeding a collection of VOs to your view component doesn't add a 'bad' coupling. A 'bad' coupling is when the view component knows about how to reach into the Model tier and manipulate the Proxy that holds the data. Or when the Proxies in the Model tier know how to get their hands on the view components or their Mediators to poke data into them.
Mediator is adding things to the View,
which defeats the point of the
separation of Mediator and View.
As Coded Signal pointed out, we're not trying to separate the Mediator from the View component. The Mediator is the one actor in the PureMVC system that should know the view component, and mediate the communications between it and the rest of the system. The Mediator is the most critical actor in the system with regard to loosening the coupling between the View tier and the Model tier.
To communicate with the view component, other actors send notifications, which the Mediator hears and responds to by manipulating the view component's exposed API; spoonfeeding it data or invoking methods on it. This effectively keeps the rest of the app from needing to know anything about the component.
The Mediator also listens to the component for events and acts on its behalf, retrieving data from the Model tier, or sending notes to to other Mediators or to trigger Commands in the Controller tier. This keeps the component from having to know anything about the system it is connected to. It simply exposes an API of properties and methods, encapsulates its own behavior and sends events when things happen that the system should know about.
So together, the Mediators and View components make up the View Tier of the application.
-=Cliff>
Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View
Not really: they're what the documentation refers to as a collaboration pair and should be treated as such.