Using Ember.ListView with Ember-CLI - ember.js

What's the most correct way to use Ember list view with ember-cli?
The docs still show the {{#collection}} helper, and even though that works, that helper has been deprecated.
I tried using {{#view 'list-view'}}, and it didn't throw any errors, but it also didn't work. I believe it didn't render the itemView.

I didn't tackle whether it should use collection or view, but I did find a way to load list-view into an ember-cli project (when ember-cli is at version 0.0.40 or less).
I submitted the solution as an Ember-CLI pull request. Since it's a version-specific solution, I won't be surprised if they don't merge it, but it might be a "magnet" for even better solutions.
Look in my proposed README under Installation.

Related

how handlebar templates are rendered by the browser

I want to know the low-level implementation of ember framework. When the handlebar templates defined inside script tag with type="text/x-handlebars-template" getting appended to the DOM? Also, how browser excludes that script?(i.e How actual flow of rendering a page is modified. I am new to ember and handlebars and just curious to know this.
I just run a couple of experiments with an older version of Ember for understanding more, what is really happening under the hood. (It is totally relevant to the latest Ember versions also.) You can read my findings in the Readme here: https://github.com/zoltan-nz/ember-resolver-experiment
Answering for your question, Ember will run the following function during the initialization process: https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/lib/system/bootstrap.js#L40
As you see, there is a bootstrap function, which uses jQuery to find those special templates scripts in your DOM. It will compile with the ember-template-compiler and it will be added to the Ember.TEMPLATES object. (You can check in your console if you type Ember.TEMPLATES.)
As you see in this bootstrap function, these template script tags will be removed (line 72) from the DOM after compilation.
Each version of Ember package comes with different ember.js files (for production, and for debugging) and you can find there ember-template-compiler.js, which is basically the handlebar compiler. You don't need handlebar.js at all in ember project, because this ember-template-compiler.js is your handlebar.js.
If you would like to learn more about Ember.js, I wrote a free tutorial which start from the very basics: Ember.js tutorial
For the last question first :
A script is never seen in a browser so there is no need to exclude it from beeing rendered. WebComponent templates are now a replacement for such script template but if you are using some older template they will still be displayed so a script tag is a better solution for now if you want a template to be compatible with all browsers. So the rendering of the page is not affected. At the end of the page load you'll run your handlebar script that will calculate the template rendering and once it's done will insert it in the dom (typically replace a placeholder).
For your first question :
The question is unclear do you want to know how the template is appended to the dom or when it is appended or how it is rendered ? The best way to know that is to look at the source of handlebars.js. I don't know for ember.js but if you're just using handlebar you'll have to add the result of your processing manually in the dom (by using jquery for instance).

Create loading substate for application route

I'm trying to create a loading substate for the Application route using the new named substate options added recently, but for some reason, I can't get it to work. Originally, I just had created a simple template, loading.hbs, and it worked automatically, but because of the issues with substates on the application route, some of my UI was still visible. I'd like to correct this now.
I've tried renaming and moving the template around to the following places:
/templates/application_loading.hbs
/templates/application-loading.hbs
/templates/application/loading.hbs
None seem to work though. I don't need any custom routing behavior so the default generated route should do me, unless its a requirement for this to work. Documentation on this feature seems to be sparse. I found the jsbin for this feature and I should be doing it correctly according to it unless there's some issue with ember-cli.
Thank you for any assistance.
DEBUG: -------------------------------
DEBUG: Ember : 1.11.1
DEBUG: Ember Data : 1.0.0-beta.16.1
DEBUG: jQuery : 1.11.2
DEBUG: -------------------------------
I believe that loading.hbs and error.hbs are the application's loading and error substates. Your application-loading.hbs doesn't exist to Ember, which is why it's not working.
As for the additional UI elements: I believe the rest of application.hbs is going to render regardless, so the only suggestion I would have is to nest all those elements one level deeper. It sounds like a big ordeal, but it's actually not that bad:
In router.js:
this.resource('whatever', {path: '/'} function() {
// All your existing routes
});
Then rename application.hbs to whatever.hbs and change application.hbs to just have {{outlet}} in it. This should really change very little else in practice, but it will keep the rest of your UI elements from rendering until loading is complete.
Really should've google it before adding the bounty.
Evidently, this feature is broken. There's a fix already though, just needs to be merged and released.
It looks like you must have a moduleBasedResolver
https://github.com/emberjs/ember.js/blob/06e41ad7ccd28558dd4e651aa070bc06f7757821/packages/ember-application/lib/system/application-instance.js#L153
https://github.com/emberjs/ember.js/blob/b80d66f71d75ad0db9022438ed58a41ac84f45f5/packages/ember-routing/lib/system/router.js#L79
When I look at this value in an ember-cli app it's undefined. Which seems odd because ember-cli is es6 module based.
Then I found this https://github.com/emberjs/ember.js/issues/10756 looks like you can add a route application-loading or hack in moduleBasedResolver onto the registry as a temporary solution.
and
https://github.com/emberjs/ember.js/pull/10944
should fix the issue in the longer term.
It appears you already found this, it did not appear loaded when I wrote this answer. Sorry for the noise.

Ember Handlebars link-to vs linkTo

When you look at a lot of the older (Pre 1.0) Ember code, it seems like the Handlebars helper is {{#linkTo}} (see, for example this SO post from January 2013). Now, the method seems to be {{#link-to}}, based on the official Ember docs.
I can't find any mention of when the helper method changed. But I just tried both {{#link-to}} and {{#linkTo}} in an app using Ember 1.2 and Handlebars 1.1.2 and both work as expected.
Two questions. When did this change occur? I can't find any mention of it in Handlebars changelogs or anything that mentions it. And 2, I assume that since {{#link-to}} is what's currently in the docs, that's the new way. But there's no deprecation notice. Is there a plan to no longer support {{#linkTo}}? If so, when? Which Ember/Handlebars version? For bonus points, link to a an article that talks about that rationale behind this decision.
You wouldn't find anything about link-to in the changelog for Handlebars since it's a helper class for Ember and not included in the main Handlebars library.
According to the blog post for RC8 the old syntax has been "soft deprecated". The old method is marked with #deprecated in the source but doesn't log anything even if used (not even with Ember.ENV.RAISE_ON_DEPRECATION set).
You will also see there that the old one is kept as a straight alias to the new one with no real implementation of it's own.
Ember.Handlebars.registerHelper('linkTo', Ember.Handlebars.helpers['link-to']);
Since they plan to use semantic versioning (as said in the post for the 1.0 release) for their releases they can't really remove this helper until they hit 2.0 though.
The linkTo and bindAttr are changed to link-to and bind-attr in this pull request. The hyphenated form was used, because is more close to web components custom elements syntax. So use the hyphenated form if avaliable in your current version.

How to make basic ember setup in jsFiddle

I'm trying to test my ember code in my jsFiddle
I set framework to Ember 1.0.0-rc1 and onDomReady
and I added jQuery as a resource.
and I setup basic application template in html and declare application in js.
I think I set very basic of an ember app. but it doesn't work.
What am I missing here?
There is an up to date fiddle/jsbin link in the Ember Contributing document:
https://github.com/emberjs/ember.js/blob/master/CONTRIBUTING.md
It is always up to date with the master version of ember.
Two things are going wrong here.
There is a bug in the way jsFiddle has implemented ember support. First off it should be including jQuery, and also it is loading ember before handlebars. You can see what's going on by right-clicking on the output frame and selecting view-source. As a workaround, manually add references to these libraries.
You've got a typo. Instead of type="type/handlebars" you should specify type="text/handlebars"
Working fiddle here
You should definitely use emberjs.jsbin.com. It has everything already setup.

Why is my {{#each}} not working?

Why is the Ember Snippet i have linked not working? I am setting up a simple ArrayController and fill it with contents upon initialization. Then i want to display the contents of this controller with the help of {{#each}}, but this is not working.
In tutorials i have read through, the following structure is always used:
{{#each AppNamespace.myModelController}}
...
{{each}}
But to make my example work i had to use:
{{#each AppNamespace.myModelController.content}}
...
{{/each}}
Could you have a look at the provided fiddle and tell me what is wrong with it? I assume that i must have done something wrong since i have seen this pattern so often in tutorials.
Note: I am a Javascript beginner coming from Java Server Development. So it maybe easy JS basics that i am struggling with.
I would have posted the complete code here, but the formatting was not working properly.
Link to my JS Fiddle showing my problem
Add a call to this._super() inside your init method.
https://github.com/emberjs/ember.js/pull/1251
Also, not directly related to your question, but it looks like you would benefit from reading #6 here: http://codebrief.com/2012/03/eight-ember-dot-js-gotchas-with-workarounds/
Tried your fiddle with http://cloud.github.com/downloads/emberjs/ember.js/ember-0.9.6.min.js instead of 1.0 pre it is working fine in both the cases.
I'm starting to look at Ember myself and I'm concerned about the process you're using.
As far as I'm aware you shouldn't really be retrieving data directly from the controller like that. The pattern you use should be based upon models, controllers, views and the router.
http://trek.github.com/ is a resource which I have found useful while learning about Ember.
Based upon that example, this would be my take on a small ember test application:
http://jsfiddle.net/zDfBv/
Hopefully that will be of some use to you as a starting point.
If you pass 1 argument to the #each helper it needs to be a Ember.Array compatible object-- in your first example you pass the controller when your data is in the content property.. your second example works because you pass the content property.. and there is nothing wrong with doing it that way if you feel like it.
There is however an alternate syntax for the #each helper which you may see more often, it uses element naming {{#each model in myModelController}} ... {{/each}}. When you do it this way Ember takes care of looking for the content property for you because it's the default rendering context for the view.
Assuming you're using the latest version from Github you'll find it takes care of looking for content in both cases so the point becomes moot once that is released as stable.