I've been using Ember for a while but still struggling sometimes to find out the best practices. So one of the Ember ways regarding controller and view is
an opinion of Ember's designers, that is enforced by the router is that for a given BaseName (e.g. "Application," "CustomerEntry," "My Items") there should be a BaseNameView and a BaseNameController. -- Ember guide
The problem is that what if I want multiple instances of the same view on a page. Since the controller is created during initiation of the application, they are singletons under the application namespace, which will not be able to hold two instances of the model data.
One solution I see is to create controllers(and model data) manually and pass them to views. But in this case, I'd like Ember not create controllers automatically for me. Put it another way, why would Ember creates controllers as singletons during application startup.
I think there are many use cases where a View type doesn't have a corresponding Controller type. Especially when the type of view is more like a UI widget than a full-fledged application feature. Many views can share the same controller. Take a look at this applicationView template:
<h1>Here are two files, compare them</h1>
{{view App.MyFileView contentBinding="leftFileContent"}}
{{view App.MyFileView contentBinding="rightFileContent"}}
This creates two instances of my view class and binds their content properties to two different properties on the applicationController. The controller property for both of those views is set to the singleton applicationController instance.
One possible reason why controllers are singletons could be that they're able to be addressed in the global namespace via something like App.router.myController.
Related
When applying the MVC pattern to a design with multiple classes do I need to create a model, view and controller for each of the relevant classes?
For example, for a design with a domain with UserAccount class, a MultimediaContent class, etc, would I need to design a UserAccountModel, UserAccountView, UserAccountController, and a MultimediaContentModel, MultimediaContentView, MultimediaContentController, etc?
I've looked for examples online but they all use a single class.
In the he original MVC as decribed by its inventor a:
an application should have one controller
a controller can provide input and commands to several views,
an applications can manage multiple models.
This is is a very high level description because each of these main "components" could be made of multiple classes. So it is fully up to you to decide of the best mapping.
Other principles, such as the separation of concerns, would suggest to have different views for different model objects. So a UserAccount, and a UserAccountView is in general a sound approach. But you could still have combo views that refer to serveral different model objects at once.
You will find many more flavors of MVC regarding the controller. The single controller monopolizing the user input and controlling all the views and commanding the domains, is no longer a reality, since many windowing system attach the controller to a window. So you'd probably have a swarm of controller, with an AppController and an additional controller for each view, e.g. UserAccountViewController, rather than a controller per domain object.
Of course, in a very simple application, with a few relatively independent domain object, each having a single view, you could find the objects as you describe them.
It seems like I can declare computed properties in the model and in the controller. I'm getting to the point where I'm not sure which one to look in for a given property.
What dictates whether a property should be placed in the controller vs the model?
Typically, place in the controller if the property is presentational in nature (e.g. display, labels, formatting), and place in the model if the property is inherent to the record itself (e.g. calculations, associations)
In practical terms though:
Model if the property
needs to be accessed by other models, since models don't have access to their controllers
needs to be accessed in routes before controllers are setup
needs to persist across controllers (e.g. order.subtotal is used in OrderNewController and OrderController)
Controller if the property
only needs to be accessed by the view or template
only needs to be accessed by other controllers
You can probably go with putting most properties in the controller, until you run into situations where you need to access the property from other models, or if you find yourself writing {{controllers.modelName.property}} too many times.
I'm trying to understand controllers in the new router system. I understand they exist to decorate models and present non-permanent state to the view/template for rendering. And I understand the conventions the Ember router uses to instantiate and set up single copies of each controller from route names. But does that mean you should never have more than one copy of a controller?
Here's my use case: I have a set of nested lists of items with complex non-persistent per-item state (different levels of collapsed / visible nesting, different editing modes, etc). I don't think this belongs in the view, and it's too complicated (because of nesting) to keep in a singleton controller -- so I was planning to have one controller instance per one view instance (all the same controller and view class though). Is this sound?
Second, simpler question. How do I access the controllers that Ember router instantiates? Previously, you could do App.get('router.postController') but that no longer works.
First Question
Not all controllers are singletons. There are cases where Ember.js creates non-singleton controllers for you.
One case is when using itemController with {{each}} helper:
{{#each model itemController="post"}}
<!-- template here -->
{{/each}}
This will create a new instance of App.PostController for every post item in the loop.
One other case is when you use the {{render}} helper and pass a model to it:
{{render "post" firstPost}}
{{render "post" secondPost}}
This will create a separate App.PostController instance for every {{render}}.
Second Question
It depends where you want to access them from.
From the route:
this.controllerFor("post");
From another controller:
App.CommentController = Ember.ObjectController.extend({
needs: ['post'],
test: function() {
return this.get('controllers.post'); // this returns the post controller
}
});
More info on that here: http://emberjs.com/guides/controllers/dependencies-between-controllers/
From the view:
this.get('controller');
I find myself needing to have a View expose its Model and Controller references. Is this the smell of bad design? Or is this considered "safe" practice?
For example: I have a list (composed of a ListView, ListController, and ListModel) and many list items (composed of a ItemView, ItemController, and ItemModel).
When I create the ItemModel, ItemView, and ItemController for each list item, I pass the ItemView instance off to the ListView. But, at some later point, my ListController needs a reference to the corresponding ItemController instance.
So, would it be more proper to pass both the ItemView and the ItemController in to ListView::addItem(), or just pass in ItemView and expose an instance method such as ItemView::getController()?
Or doesn't it matter? Is each approach equally viable? If followed to their logical conclusion, does either tactic result in an anti-pattern?
But, at some later point, my ListController needs a reference to the corresponding ItemController instance
Why? If you're decoupling your classes properly, you shouldn't need this.
Controllers almost always address a functional domain. An example of such a domain might be "Sales" or "Admin." In addition, MVC also supports the use of "Areas," which provides an additional hierarchical level of organization.
Adding references to controllers from other controllers is at cross-purposes with this organizational structure. If you need to combine functionality to make your code more DRY, ordinary refactoring will accomplish that. You can also inherit controllers from a base class containing common functionality.
In the mvc pattern the users request shall be routed to a controller, say invoicecontroller, that has actions.
Lets say the default action, Index, returns a list of invoices; the controller then creates a model with a list of invoice objects, instantiates the correct view and injects the model into the view.
Now it is the views turn to do its magic. It renders the best view it can with the data it has, which may include routes to one or more controllers.
In NO instance should the view (or model) do business logic themselves.
That said, I totally agree with Jakub. Hope that helps.
Considering you are not actually showing any code at all.
In my opinion, you should change your design. A controller is not supposed to communicate with another controller (directly), MVC dictates it: reference.
If you need to invoke a controller action from another controller, consider using delegates or composition. Instead of directly invoking the controller action.
I'm just learning MVC so you could find my question rather strange...
My Controller have access to different shared objects through Container object passed to Controller's constructor. To access shared objects I should do $this->container->db to access Database adapter or $this->container->memcache to access Memcached adapter. I want to know should I put View object into Container with shared objects or no?
From one side it is really comfortable to take view from this container, but this way I couldn't create multiple Views instances (for example, every time I'm calling Controller's method from View I should have one more View instance). What is the solution? How should I pass View object into Controller and/or how should I create new View instances from Controller?
Thank you!
If you want that DI experience, do it on views as well, but I don't know if it really helps you anyway. Never call controller methods from views. Instead write some partial view methods and call them from views, which define the page layout (something similar to what Rails does).
IMHO if you want to get on MVC gradually, start from core principles and iteratively get to details, but don't learn architectural/design pattern as MVC by parts - architecture, design, the whole matters:)
Hmm, maybe try implementing caching for static parts. IMHO try inserting cacher object (through DI) to controller, and let that object decide if you want to send cached partial view or instantiate a new one. If you want to cache data from db, use the same pattern from controller towards models, so whenever in a controller you need models, ask db cacher object (same DI principle). Is it clear enough?