Lets assume that I have two routes in an Ember application. These are totally separate routes names 'first' and 'second'. They have separate data models and different actions and so forth.
Everything is fine up to now.
How - we recognise that these parts of the application:
Are often used by the user together in an alternating fashion (do something in first, then in second then two things in first etc)
They take up little screen real-estate.
In a standard server side application, we would assume that we can create a new dashboard controller/view and somehow real in the other two controllers to handle all the things and diplay the results. The crucial thing is - composition does not change the 'first' and 'second' controllers or views.
I want to do the same thing, only in Ember. I've created this JSBIN to illustrate the problem.
I am aware of two existing solutions:
Use the existing models only (solution in the linked jsbin above) - the problem with this approach is obvious - the view are not used.
Use the Component approach - I believe that this is not a good fit because these are not general, reusable components, and should be able to stand up on their own.
An ideal approach for me would be to use the {{view}} helper to somehow invoke the views but also pass in the controller data. (I've had a go at it in this jsbin but can't get seem to get it to work the the data from the controllers or properly setup a model for the route).
In my opinion you will need to use the {{render}} helper
App.CompositeRoute = Ember.Route.extend({
model: function(){
return {
first: this.modelFor('first'),
second: this.modelFor('second')
};
}
});
in your handlebars template for the composite
{{render "first" model.first}}
{{render "second" model.second}}
Good luck
Related
i'm very confuse about how ember controller works.
I'm starting with ember and ember-cli now, and i would like to understand more about how controller works.
If i have an nested route called new, inside a events resource, i should i have:
models/event
routes/events/new
templates/events/new
What about controllers?? I just work one simple controller, or should i use controllers/events/new too?
There isn't any generator command that will create every resource for me? I need call one by one?
Thanks.
What about controllers?? I just work one simple controller, or should i use controllers/events/new too?
This mainly depends on what is your controller needs to do. If it's only the essential stuff the controller does anyways, Ember will create that controller under the hood for you and automatically bubble actions up to its parent controller.
No better place than Ember guides to read what a controller is used for:
The simplest definition is:
Controllers allow you to decorate your models with display logic.
This means that you basically use them as the main communication layer between your route and your template. Essentially, you model comes from your route, through your controller and into your template. Actions happening in the template go up to the controller and then to the route. Therefore, controller is essentially the middle layer where you user your model (and other data) to control what is shown to the user, control what a user can do, control where can they navigate etc.
However, be aware of the plan for the future:
Controllers are very much like components, so much so that in future versions of Ember, controllers will be replaced entirely with components. At the moment, components cannot be routed to, but when this changes, it will be recommended to replace all controllers with components.
This means, that right now, controller responsibility is limited to two things:
Maintaining application state based on the current route
Handling or bubbling user actions that pass through the controller layer when moving from a component to a route.
All actions triggered on a template are first looked up on the controller, if it is not handled or bubbled (by return true) in the controller, they are looked up on the route.
Therefore, controllers for your /events or events/new routes aren't necessary at all, only if you want to handle things happening on those routes right away (in a smaller scope) instead of allowing everything to bubble up to the ApplicationController.
There isn't any generator command that will create every resource for me? I need call one by one?
Yes. Since, if you don't specifically create a controller, Ember just generates one for you behind the scenes. You need to specify where you want to handle things yourself.
You should visit the link I gave above (or here it is again) to the Ember guides that have many more examples in much more detail.
I'm working on Angular seed in my project.
I have two identical views(HTML pages) which are same (having same elements and functionality).
These two pages have GridView that are to be populated by same service as well but only the REST API URL is different for both of these pages. Now in my router.js, I want to use $stateprovider.state() to route to these pages.
My question is: Can I use a single controller for both these views or a separate controller for each. But, when I use the same controller for both view pages I get "Injector not defined" error.
Is there a different way to do it? What is the best procedure to handle such conditions?
This is a bit of a generic answer, I can update it if you provide some additional details or code. It's possible to use the same controller for different views. Although personally, I tend to try to avoid this, in case I later have to mod one of the views. I would use two different controllers, but put a lot of common code in a service/directives. I think it's a good practice to minimize the amount of business logic in your controllers.
If you have identical views, that only change an url, I would consider using an url parameter or route parameter for this. Then you would in reality only have one view and one controller.
I'm new to Ember, come from an Angular background. Let's say I have an number of elements, each of which holds a different data.
#elem1 10
#elem2 20
#elem3 30
I want to bind each of these elements individually to Ember models/controllers that hold the data. So something like:
script(type="text/x-handlebars", data-template-name="elem1").
{{data}}
App.Elem1Controller = Ember.ObjectController.extend({
data: 10
});
This should be really easy... but I'm having a hard time navigating through all the different naming conventions and routing/terminology of Ember. How can I go about doing this?
The first thing to determine is which route and controller is associated with your view and then wire up the components accordingly.
Here is a simple example in a JSBin.
This one uses a separate controller and route for the three properties. And they are rendered into the application outlet when the link is clicked.
If you need to use multiple controllers then you can include them in the controller that is associated with your view by using the "needs" dependency injection.
Here is another one that just uses the application template and associated controllers etc.
It also shows how you can include controllers in other controllers which might be more what you are looking for. It also shows you how to reference them in the template.
I'm making a single page application using Require.js and Backbone.js. Its a fairly large web app with a lot of different "pages" aka views. Below is my router to give you an idea. There are several main pages with sub pages.
So for example there's a Settings section that has multiple different sub pages such as user settings, language settings, email settings etc.
How would I structure many routes and their views for simplicity?
Right now Im giving each sub page its own view but that means I have to import 20-30 views into the router so that all possible views are available for when that page is routed.
Another way I thought of was to have one view for each section and that in that view I should load different partials. That way I only have to load the 5-6 section views into the router... but then the view would have to understand routing.
Whats the right way to do this?
I create 'controller' objects that take care of view rendering and model fetches.
I prefer to keep the router clean at all times, which means that I will don't clutter it with callback functionality. Doing so would make the router a mess over time, while part of its purpose would be to get a quick overview of the available routes.
In Backbone, I found that it is useful to create your own conventions, just like a framework would do.
For example, for every view I create, I will create one controller object.
Every controller object has a method that is named 'makeView()', and which takes care of rendering the view, as well as memory management.
In my own theory, I created a method of 'cascading controllers', in the sense that one controller may also control other controllers, and controllers may use 'helper' objects to fulfil certain tasks.
For example, when you say that you may need to manage 20 views and subviews; we could imagine that some of the views are related to each other; that there will be a central controller that takes care of common tasks between related views, and specific controllers that take care of specific, individual view functionality.
A route in my router looks something like this:
auth: function(){
//--- Check the authStatus and render status independent views
var auth_ctr = new Auth_ctr();
auth_ctr.makeViews();
}
In the example given, you could imagine that you will create and render multiple views. So what I really do, is instantiate new controllers from within this controllers, that each individually will create and manage views, provide functionality that support the view, get the collection/model data.
It would be important to create a sort of independent 'View manager' that prevents memory leaks from occurring when you render new views each time.
This is just how I do it, but of course, I'm sure there are people who do this differently.
It is a theory I came up with; it has given me a clear structure, and it has worked well for me until now.
I'm writing a large scale marionette application, which is ran initially from a router / controller.
Here's my question -- is it good practice to include other functions in your controller that aren't meant for routes?
So say I have the following method:
index : function() {
alert('test!');
}
is it consistent with best practices to be able to declare other functions in the controller not called when routes are initialized? Like so:
noRouteAssociated: function() {
alert('test!');
}
index: function() {
this.noRouteAssociated();
}
Obviously this is a simplified example, but I am trying to avoid putting large amounts of information or function declarations inside of methods only because they're associated with routers.
The roles and responsibilities of controllers are best illustrated by #davidsulc in this SO post and better yet his new book.
Generally speaking, it's okay to include methods that aren't meant for routes, if they're controlling the workflow of your app. Event triggering is a good example, but if you want to change the appearance of something or retrieve data from a database, you should move these methods to a view or model, respectively. The block quote below is taken directly from Marionette's controller documentation.
The name Controller is bound to cause a bit of confusion, which is rather unfortunate. There was some discussion and debate about what to call this object, the idea that people would confuse this with an MVC style controller came up a number of times. In the end, we decided to call this a controller anyways, as the typical use case is to control the workflow and process of an application and / or module.
But the truth is, this is a very generic, multi-purpose object that can serve many different roles in many different scenarios. We are always open to suggestions, with good reason and discussion, on renaming objects to be more descriptive, less confusing, etc. If you would like to suggest a different name, please do so in either the mailing list or the github issues list.