I know this is a very basic question, but it matters a lot for developers. Basically, I just need to know that when developers should use view rendering and controller rendering.
To put it briefly, view rendering is to simply display data. It can be controller by the front end via filtering or transforming it but it will not interact with any of the underlying business logic.
Whereas a controller rendering is more so used when the user is going to manipulate that data on the backend and will have to follow those business rules.
Is that sufficient?
Related
Is the document/view architecture in MFC really a Model/View/Controller pattern without the controller part?
I'm studying MFC and I simply love it to bits. I know is somewhat outdated and somewhat bit more difficult to use, but I discovered that it gives me so much more power and performance gain when compared to QT.
Am I correct to think of the MFC doc/view model as simply MVC without the Controller part?
The Model/View/Controler has the following components:
Model
View: responsible to show the model to the user
Controller: responsible to get user input and translate it in operations on the model
MFC's Document/View has only 2 components:
The document, which is in fact our model
The View, which has the responsibility to show the Document AND interpret the user's commands. So it is the view+controller (refer to section Variants in this MSDN article)
Let's look at it:
The view contains UI code, both for rendering the data and for taking input from the user.
The document contains the serialization code.
From that perspective, there's just a separation between UI and a backend. However, there's more, because you can have multiple different views on the same document. You could also use the document to just provide data storage and put any actual program logic into the view. In particular when you only effectively use a single view per document, it is easy to blur the separation in practice.
In summary, I wouldn't say the MVC controller part is missing but that it's merged with the MVC view parts into the MFC view.
I'm looking at creating a google maps component. But I would like it to be self contained so it will have its own model, controllers and views. So for example the component will fetch its own data from the server and I'll also be able to refresh the data when needed. Ideally I'd simply add the component to the current template that is showing, so for example: {{map-view}} and then everything the component needs to do will take care of its self.
The component will also need to listen to triggered events from other controllers as a user will be able to search for a specific location and the map will need to change its position.
Is this possible to do in EmberJS? As I haven't found anything like this, specially when having its own model. I know there is a component in EmberJS but it seems very limited. Am I wrong in thinking this?
the controller cannot have its own model all values must be passed to component. Please refer to ember docs and this Discussion
You can make a google map component and pass the location and marker data to the component. this data will get updated due to ember data binding.
so you can have something like this
{{map-view location=userEnteredValue}}
you can search for ember component talk by Kris Selden on youtube which includes a google map component good for you to start with.
updated
https://gist.github.com/krisselden/8189650
I have an application scheme implemented in Ember that basically follows this layout:
The concept is that the user can interact with features on the Map View (which is always present) and basic navigation occurs between various views in the Parent View and an arbitrary stack of Sub Views. The user can create new features on the map, edit existing ones etc.
The URL for a particular feature could be /features/123/edit
Since input into my interaction panels is very much dependent on interaction with the Map View (drawing a polygon, placing a marker etc.) my controllers for these views are setup to "need" the Map Controller. When a particular panel view is present interaction with the map should affect the panels in various ways.
My question is - how does one scale such tight controller coupling? I essentially need to switch between different Map modes based on which panel is currently active. I also, I believe, need to observe events on the map and act upon such events depending on the current active panel.
I setup a proof of concept where a certain Sub View Controller observes certain properties of the Map Controller (with for example .observes("controllers.map.activecoords") however, such an observer will continue to trigger even after the user has navigated away from the particular Sub view (i.e. as soon as the controller has been initialised). Must I setup and tear down such observers manually (i.e. using addObserver) when entering and leaving the route? Is this the right pattern? I've gotten the impression that requires that I manually remove all such observers during transitions to avoid unexpected behaviour and memory leaks.
Perhaps I'm going about this completely the wrong way? Are there any others patterns that fits my use case with an always present map with different states and intercommunication with interaction panels?
Perhaps the architecture of your application shouldn't be connecting controllers, but rather ask yourself "What is the model here, really?"
In each case, I think the model is your map, or at least its "contents". The features are really decorating the interaction with your central model, which is the map, underlying it all.
So really you have a single model here. You effectively have a map resource, and many feature routes on that resource, viewed from the URL/API.
The question is now not so much "how to manage a dependency hierarchy between controllers?" as "how do I manage a view and a subview on the same model?" which is answered quite simply in the standard ember nested route. Your outer view is always present and it has an outlet which is where your feature goes. How it's rendered is the inverse of how the standard nested route is rendered, but nevertheless it's the same pattern.
So, the TL;DR answer is... go through your model and the routes... use them to talk about your common data: the model is, afterall, your data, and the controllers and views are simply augmenting and enabling the user experience, presentation and interaction of them.
Most of these sorts of architectural problems can be resolved by moving the data up and down the hierarchy (template view / component / controller / route / model) until you find a place which is low enough to still be accessible to objects that need access to it, yet high enough that it makes sense by not being tightly bound with too many things, but still is in the right spot and "feels right".
If it's too high, you'll tend to be doing the wrong kind of work with your objects (ie controllers should not be mucking with view mechanics, models shouldn't really have presentation stuff in them, etc.
If it's too low, you'll tend to be doing too much work with the framework and you'll tend to be repeating yourself a lot... ie controllers will be doing a lot of work to get the data they need, for example.
I'd like some examples please of how you use Ember.Controller objects. Apart from the StateManager, I really don't find myself using Ember.Controllers much at all. In the Ember source code it says that actions should be sent to the controller, but I really don't find myself using these so much, because I abstract the views so much, and therefore use the in-built actions like click, change, and keyUp. Am I abstracting too much?
For instance, if I'm displaying a button on the page, then I'll create a new Ember.View in my controller view, and then simply include that on the page.
Most direct interaction with controllers is indeed through the StateManager/Router. The controller's main responsibility is to present data to the views for rendering. They do this by proxying to models as well as maintaining transient state.
You are also correct that a single controller can often be responsible for a hierarchy of views.
I recently did a talk about the responsibilities of various layers in Ember apps. Slides are here: http://www.lukemelia.com/devblog/archives/2012/08/23/architecting-ember-js-apps/
This website has a pretty good presentation of how to use each part of Ember's MVC, and their relationship with each other:
http://www.lukemelia.com/blog/archives/2012/08/23/architecting-ember-js-apps/
Are controllers in ember.js meant to be tied to main view areas/scenes a la iOS, or more tied to a set of data?
Is it common/wise to have several main views tied to the same controller in ember?
In iOS main portions or sections of the screen are tied to a single controller. If you want to present another main interface, say a modal window to create a new element, you (typically) have an entirely separate controller to manage that view and its data/logic.
In something like Zend Framework, you have controllers that might perform some common spinup steps of ensuring authentication, but largely the actions play the role that controllers do in iOS, handling the logic and providing the data for 1 main section or view (being the web, this usually ends up being the whole page).
What is that typical role or advised pattern for using controllers in ember?
You have a couple different questions here so I'll address them one at a time.
First, you asked if controllers should be data oriented or view oriented. In my experience both behaviors are allowable. Controllers are an excellent way to manage data sets for your application, including things like filtering and searching. Evin Grano wrote a good post about this from the SproutCore perspective and most of the concepts should apply to Ember as well: http://www.itsgotwhatplantscrave.com/2009/07/30/root-controller-paradigm/. Controllers are also well suited for controlling the application state and behavior. For example, you might put a method in a controller that is bound to as a button action elsewhere in your app. However, you should also examine Ember States to see if these might be better suited to your scenario.
Secondly, you asked about tying multiple views to the same controller. Personally, I see no concerns with this as long as the controller maintains a distinct purpose. If the views are logically related and share in the same state or data then a single controller makes sense. If you find the controller growing to cover too many different areas, you should consider splitting it into multiple controllers.
From my limited experience in Ember.js, I have regulate to the following:
The view handles user actions related to changes in the presentation layer, limited to its own instance.
A navigation controller/statemanager handles complex manipulation of what is presented (add multiple views, remove some other, etc.).
The controller responds to user actions related to the data layer.