Ember.js Tabbed Page

Question

I have a complex form that I want to display on the issue/:id/edit track. The only way to show all I need is to use multiple tabs. See the included sketch to make the situation clearer:

So what is the “canonical” way to do this using the Ember platform?

My first attempt:

Sample 1: Particles

Thus, all data is loaded and attached to a single tickets/:id/edit route and to the controller. I used partial files to load various tabs.

This worked perfectly. However, as the application grew, one controller became too small to handle everything. There were dozens of properties, and there is no clear indication of what usually and what belongs to individual pages. Thus, I decided that I needed to somehow separate the logic of the individual tabs into my “things”.

Sample 2: Routes

Each tab has its own route and controller. All data is loaded into the base route /tickets/:id/edit , all child routes "borrow" what they need from there.

 setupController: function (controller, models) { var ticket = this.modelFor("ticketEdit").ticket; controller.set("model", ticket ); } 

^{Example from one of the child routes}

I'm halfway to implementing this, and I'm already struggling with problems. I need people not to visit the bare /edit route. I need to prohibit page navigation in browser history. I need to customize my breadcrumbs and other widgets.

I can figure it all out on my own (this is not a question), but I'm not sure if it is worth the effort. The bottom line is that the route is not ideal for what I need. Therefore, before I throw more time into the river, I suggest that it is better to stop and think about whether there is a better pattern.

Two candidates come to mind.

Sample 3: Views

Therefore, I can create a separate view for each tab. All of them will share TicketEditController , but I could collect them using some custom materials so that I can facilitate downloading from a common controller.

Bottom side: it pollutes the water. Some of the widgets that I need to display are the views themselves and may assume that they will be created from the controller. Not sure how it will scale when I start adding views to the views in the views.

However, this seems like the best option. But am I missing something? Should I abandon the route scheme?

Figure 4: Components

Similar to the view. Technically feasible, but will require significant refactoring of many widgets, which assume that they have direct access to the shared controller. But is there huge potential for this approach? Not sure.

Sample 5:

???

---

So, this is where you entered.

• What do you think of these approaches?
• Which one are you using?
• What are some problems or benefits that I am missing about any of them?
• Can you define "pattern 5", or are these all viable approaches to this problem?

Answer 1

I want to at least leave my thoughts here, as you are looking for feedback.

Of the identified patterns, I prefer the first two. The difference, in my opinion, is the ability to bookmark / navigate tabs. I would like you to be able to send someone to edit a specific tab using a URL (so I would prefer # 2), but it looks like your requirements are to keep the traditional tabbed behavior (where the tabs are are not pages and backstrokes will not lead you to the previous tab). So yes, you could manage your browsing history , but it looks like you have other parts (breadcrumbs / widgets) that you will need to address as well in order to weigh you the cost.

crescent mixin idea

The main drawback of the Particle Template was a monolithic controller. I wonder if you would be better off creating mixins controllers, making it clear what properties are for each tab. Perhaps each tab is a mixin:

 App.TicketEditController = Ember.ObjectController.extend( App.TicketEditGeneralTabMixin, App.TicketEditTextTabMixin, ... { //common properties }); 

different

You can consider http://discuss.emberjs.com/ as another place to get a response to this.

A code review might be another place to think.