Does anyone know of any good examples or straightforward documentation that talks about the programatic creation of templates (and by extension components) without explicitly writing out handlebars template code and markup? In either script tags or separate handlebars file.
Perhaps a hello world or ember starter kit example that is pure javascript and does not have any HTML script tags defined.
Is this possible?
Why would you want to do this? Even ApplicationView uses a string template when setting a default template for ApplicationView. Itās just ā{{outlet}}ā, why would you not do the same?
I guess I was just curious if it was possible. Perhaps the use case is that I might want to create an array of component instances and then programmatically push them to DOM.
But mostly just curious if it was possible.
Curiosity is an attribute of a great mind 
Iāve actually seen something similar done before. Checkout the Customer Rendering section on Evil Troutās blog post about Custom Views.
Try looking here:
https://github.com/emberjs/ember.js/blob/master/packages/ember-handlebars/lib/controls/select.js#L21
You can override template or defaultTemplate to possibly achieve what youāre trying to do, if you reaaaally need/want to do it (though it seems unnecessary).
You could feasibly do something like
defaultTemplate: function(context, options) {
options = { data: options.data, hash: {} };
Ember.Handlebars.helpers.view.call(context, SomeViewOrComponentClass, options);
Ember.Handlebars.helpers.view.call(context, SomeViewOrComponentClass, options);
Ember.Handlebars.helpers.view.call(context, SomeViewOrComponentClass, options);
Ember.Handlebars.helpers.view.call(context, SomeViewOrComponentClass, options);
Ember.Handlebars.helpers.view.call(context, SomeViewOrComponentClass, options);
},
I havenāt actually tried this out but should probably work without too much crazy hacking.
Thanks @tarasm and @machty for the links and info. I think I just learn best when I try to understand it from the inside out. Trying to get to the point where I have to refer to the documentation less, because I just know how the underlying code actually works.
And @machty perfect! I didnāt think to go look at how the built in views like select are implemented. Good info there. And helps me understand handlebars a little better too!
No not at all. It is all good. Didnāt take anything personal. And by the way great work on the EmberSherpa. I like where that is going.
That is a worthy topic. It seems there is still not a lot of info around creating, modifying and committing data and models. Look forward to it.
If you find time, also might be useful to briefly touch about the backend side of that. Basically what should happen when you push data over the wire via PUT and when manipulating with DELETE.
If all permits, Iāll go down the stack and probably into PHP and Node.js side of things because Rails is well covered by EVERYone else
Makes sense. On php are you going to use Symfony? Or vanilla PHP? There is also Yii, which might be of interest.
I actually havenāt written anything in Symphony or Yii before. Iād love to get a contribution from someone who has.
I havenāt actually seen a good implementation of an API server for PHP. If you know of one, Iād like to look at it.
Rolling one from scratch is not difficult, but I wouldnāt encourage anyone to do it. Iām still unsure about how to handle those scenarios.
I havenāt done Symfony work since the 1.0 days. But my impression was that it was very rails like. You have a CLI, some generators, actions, ORM (propel, doctrine) and a general MVC architecture. I think Symfony has evolved a bit but havenāt kept up with the 2.0 stuff.
This might have some promise.
If you do get started on this and have any specific questions ping me, I might be able to answer a few things.
On second thought, I donāt think that people who use Symfony would need help setting up APIs, or at least not the majority of them. Without solid statistics, its difficult to tell but my sense is that there are more people whoāre coming from other frameworks than Symfony.
But I really donāt know. Iāll think about it some more when I get to it. Iāll keep you posted.
Makes sense. Probably best to just focus on a ember example that does all the CRUD stuff. And then theoretically it could talk to any specific backend implementation. It would be cool if people could run with your example and build discrete backends to support the CRUD defined in your example.
In my mind a Create and Delete operation are not truly complete until something happens at the persistence DB layer. So what happens on the server matters. That is all I meant by touching on the topic of backends.
Obviously local storage is one case where server is not necessarily involved.
Iām working it downwards. First, I want to get to a point where its clear how persistence in browser happens. From there, Iāll work down to interacting with the backends and covering different kinds of backend implementations.
I tried what @machty proposed because I needed something similar. Unfortunately it works only with a single view. As soon as you instantiate more than one like this, you end up with:
Uncaught TypeError: Cannot read property 'templateData' of undefined
Inside of a view or component:
var viewClass = Ember.View.extend({ templateName: "path/to/template" });
var view = this.createChildView(viewClass);
var html = view.renderToBuffer().buffer;
```
### UPDATE:
This code works slightly better:
var viewClass = Ember.View.extend({ templateName: this.get(ācontentTemplateā) }); var view = this.createChildView(viewClass); var html = view.renderToBuffer().buffer; view.removeFromParent();