Understanding how to architect a screen

1

So, I’m very new to Ember. I’ve read through the documentation and looked at a lot of examples, however I’m struggling to understand how to architect my templates.

Most of the examples around are pretty straight forwards with a navigation area and an outlet that changes per route. What I have is a header, sidebar and main area. Each contain different model data. Dropbox - mockup.png - Simplify your life So in this mockup the hash border areas are the separate pieces of data that need to change as appropriate.

The data within the ‘Main’ area I’m pretty ok with as that will be controlled by the route the user is. However the Sidebar and Header areas are constant and as such they aren’t tied to a route. Or possibly they would be tied to the ApplicationRoute.

Some of the data in the sidebar will change over time based on interactions within the main area, so I’ve assumed I should be using live collections for those.

I’m currently feeling a bit lost as to the best way to architect this kind of thing. I’m not looking for someone to tell me how to do it, but I just want to try and understand what’s the best practice and some pointers would be great.

I was considering breaking each of the dashed areas into Views and then somehow binding models to Views. Or should I be looking at another way of doing it?

In terms of the template I currently have an Application template that have the Header and Sidebar as part of that. The Main is then the {{ outlet }} of that app. I tried having the Header and Sidebar in separate named outlets, but I didn’t like how the whole page pretty much refreshed when changing route.

Are there any good examples out there that I should / could take a look at for some more complex apps.

I think overall I’m confused as to the best way of handling multiple models without one route. I guess that’s what Views should cover?

2 Likes
2

The {{render}} helper is your friend for this type of layout. You probably want to have the bits that don’t change in your application template, and use an {{outlet}} in that template for the content that will change with the route.

I think overall I’m confused as to the best way of handling multiple models without one route. I guess that’s what Views should cover?

No, a view is an abstraction around a dom element and should primarily be concerned with handling dom events (and turning them into application-level actions).

Your routes should load your data and handle actions. Then they should assign this data or make appropriate property changes to controllers. Controllers present your data to templates (and can be linked together with the “needs” mechanism). Use your routes to set up your data, your controllers to present / wrap your data and connect it together, and templates to render the dom. Use the {{render}} helper to render specific controllers where you need them.

3 Likes
3

Thanks Alex, that’s very useful. Makes a lot of sense.