I am using Ember, Ember Data, and Handlebars to display a timeline with a number of different types of models. My current implementation, though functioning properly, seems like it could be drastically improved with a convention and a helper. However, I can't figure out how to use already defined templates.
This is what I have:
{{#view App.AccountSelectedView contentBinding="App.selectedAccountController.everythingSorted"}}
{{#with content}}
<ol class="timeline">
{{#each this}}
{{#is constructor="App.Design"}}
... stuff about the design
{{/is}}
{{#is constructor="App.Order"}}
... stuff about the order
{{/is}}
{{#is constructor="App.Message"}}
... stuff about the message
{{/is}}
{{/each}}
</ol>
{{/with}}
{{/view}}
...along with a helper...
Handlebars.registerHelper('is', function(options) {
if (this.constructor == options.hash["constructor"]) {
return options.fn(this);
}
});
I would rather rely on some convention to figure out what view to render. For example:
<script type="text/x-handlebars-template" data-model="App.Design" id="design-view">
... stuff about the design
</script>
<script type="text/x-handlebars-template" data-model="App.Order" id="order-view">
... stuff about the order
</script>
Perhaps the data-model attribute could be used to determine how an object is rendered.
{{#view App.SelectedAccountView contentBinding="App.selectedAccountController.everythingSorted"}}
{{#with content}}
<ol class="timeline">
{{#each this}}
{{viewish this}}
{{/each}}
</ol>
{{/with}}
{{/view}}
Alas, I can't figure out how to access templates from a helper.
Handlebars.registerHelper('viewish', function(options) {
// Were I able to access the templates this question
// would be unnecessary.
// Handlebars.TEMPLATES is undefined...
});
Also, is this something I should want to do with Handlebars?
I solved this by establishing my own convention using a mixin. A model corresponds to a view with a similar name. For example, an App.Design model instance corresponds to the view App.DesignView.
I mix this into my models...
...and iterate over a mixed collection like this:
This way, I avoid defining the convention explicitly in my models. Thanks to Gordon, I realized that the view could by specified using a property on an object. I would still really like to hear about the 'right' way to solve this problem.
This is what I used for a similar scenario.
Model 'page' hasMany 'activity'.
Model 'activity' has property 'type' that references which template to use for the content in another property 'configuration'.
Note the lack of attribute type for configuration. This offers the means of storing a collection of randomly structured objects. For consistently structured objects, I suggest using Ember-Data.Model-Fragments.
Main template:
For type: 'static', it uses the {{{3 mustache option}}} to render a html string.
The other options are far more complex, yet still simplified using a 'with'. ie: for type: 'multiplechoice',
With the partials, remember to consider nomenclature and/or folder structure depending on your environment, ie '_partialname.hbs' or 'viewname/partialname.hbs'
use ViewStates, see examples at:
http://jsfiddle.net/rsaccon/AD2RY/
This is just off the top of my head: I would create a separate template/view for each model type. E.g. there would be a
DesignView
,OrderView
, etc. Each of these would specify the template to use with templateName (all code coffeescript):All of the custom rendering for each type would be done inside the view/template.
At this point we need to have some template logic to decide which view to show for each item. The easiest thing to do would be to store the viewType on the model.
Then the template could look like:
This is not ideal, however, since we don't want the model to know about the view layer. Instead, we could create some factory logic to create a view for a model. Then we could create a computed property on the controller which contains an array of the models and their corresponding views:
The template would then look like this:
There are probably better ways to do this. I would love to hear someone who is closer to the core of Ember give a solution.