I hate to ask such a newbie and vague question, but I imagine there must be others out there whose brains are also about to explode. I see related questions, but none that directly addresses my confusion.
I've just been introduced to Ember.js and I'm trying to learn the basics of the Router, but I can't find two sources that agree on how this is done. I suspect that I'm jumping in during an unstable transition. I'm using the latest 1.0.0-Pre.4 release.
The best I can figure, Router is the new mechanism, and possibly replaces StateManager - yes? Yet the classes listed under 1.0.0-Pre.4 API on the web site don't even list a Router object, nor does the guide make mention of it... yet, I get no complaints from javascript when I use sample code that extends Em.Router.
Ok cool, however it then barfs on the Router member "transitionTo" which is present in many of the demo projects, but is unrecognized in the current release.
So, I guess what I'm asking is not so much a direct question, as I am looking for a grounding point in a sea of contradictory information.
If starting out with Ember.js as it is RIGHT NOW (1.0.0-pre.4), with no history to contend with, what routing mechanism should I be looking at, and is there any tutorial or simple sample app that demonstrates and runs against this version of the library? Can you confirm my suspicion that the documentation is out-of-date in regard to routing?
Ember.js is a lot to learn, and if I ever hope to figure it out, I need to know what to ignore and what to embrace.
Thank you.
The best I can figure, Router is the new mechanism, and possibly replaces StateManager - yes?
Yes, Router is the new mechanism. It does not replace StateManager per-se. Early version of the Ember Router were based on StateManager. The new one (1.0.0-pre.4) is not, but StateManager is still an important part of the ember library. Many of ember's core components (models, views) rely are built on StateManager.
Yet the classes listed under 1.0.0-Pre.4 API on the web site don't even list a Router object, nor does the guide make mention of it... yet, I get no complaints from javascript when I use sample code that extends Em.Router.
The Router does not have API docs yet. I imagine these are in the works. When in doubt about a fast-moving open source project I always have a look at the tests. Ember has a really solid test suite, and in the case of routing you can learn a lot by reading through the integration tests here: routing/basic_test.js
Ok cool, however it then barfs on the Router member "transitionTo" which is present in many of the demo projects, but is unrecognized in the current release.
Sounds like those demo projects are out of date.
Can you confirm my suspicion that the documentation is out-of-date in regard to routing?
Re: the official docs I think both the API and Guides can be considered current, but be aware that not every ember feature has API docs so far. For sure there are many out-of-date sources floating around. Trek has been working to compile a list of out-of-date sources so that we can reach out to authors for a refresh. Here on Stack Overflow, anything related to the old router should now be tagged https://stackoverflow.com/questions/tagged/ember-old-router.
If starting out with Ember.js as it is RIGHT NOW (1.0.0-pre.4), with no history to contend with, what routing mechanism should I be looking at, and is there any tutorial or simple sample app that demonstrates and runs against this version of the library?
The ember team has been putting a lot of effort over the past few months into the Ember.js Guides - AFAIK they are all up to date WRT (1.0.0-pre.4) and are becoming more solid every day. They include a lot of detail about the new Router - see Ember.js - Routing for the most up-to-date information.
As for tutorials, there are several new ones that are worth a look. Check out this SO post for a few recommendations: Could someone point me to an ember.js project that uses the latest routing system? Bonus points if it uses ember-data as well
tip: build your own version of ember from master branch - they fixed few bugs :)
Related
I am trying to move an application from using tornado templates (to be more accurate, it's jinja with an adapter) to ember.js.
It is my understanding that ember.js has very strong opinions on how to compose the final rendered product. In practice, it seems that the whole application must be generated from ember templates on the client side. The server side just provides data in REST format.
Is it possible to have ember work and take control only on some parts of a page that is mostly rendered by tornado templates (a la jquery plugins), or do I have to completely switch to ember?
Welcome, glad you're looking hard at Ember! You're right, Ember has definite opinions on how things should work :-) Despite that, it is indeed doable to migrate over in chunks.
You have a few options on how to handle this.
1. Build out from a single div on a page
You can see this in action on the builds page on the main Ember site (which is a small Ember app). Source for it is available here: https://github.com/ember-learn/builds/
Of interest is the fact that you can define the rootElement that you want Ember to render in to (see https://github.com/ember-learn/builds/blob/master/app/app.js although we should actually move that line to the config file). Once you have Ember on the page it is then possible to have it both interact with external Javascript or to have external Javascript call in as needed.
2. Sprinkle Ember components on to a page
If you need Ember to control multiple parts of the same page, you may want to look at https://github.com/mitchlloyd/ember-islands That addon is designed to work with server-rendered pages, so may not fit your setup. But it's another example of how to refactor in.
3. Use the new GlimmerJS (alpha)
You could also start refactoring into Ember using the newly announced GlimmerJS. The goal for this library is to allow folks to sprinkle in Ember and then as they need page routing and other aspects of Ember, allow them to switch over. So it may fit what you are after.
Note however that the GlimmerJS layer (on top of the Glimmer vm) is still quite new. What is there works well, but much of the Ember polish is still being added. So shipping to production could take some work ...
I'm just getting started with EmberJS and saw the "routing" example on the emberjs.com page. It takes the form of a mail client.
I've downloaded all the files (app.js, application.hbs, etc) but can't figure out how to get it to "work".
There seems to be missing an HTML as the entry point?
OR, if nothing is missing, how do I view this app within a browser?
Unfortunately, although this example makes its point (showing how you don't need a lot of code to do something that is traditionally complicated), you can't use the files directly without some tooling to compile the templates, for instance.
It is recommended for any new Ember project to use Ember CLI to do this work for you. You should check out the 'Getting Started'-section of their website, and then read through the section on using modules and the resolver, which will explain the ways in which the example you are looking at would be different.
The official Ember Guides are very good for getting started, and I'd recommend you check that out (make sure you read that modules-part if you're using ember-cli (which you should) before you go through the guides). Also, please join us on IRC on #emberjs if you have any questions that would need some more back and forth.
Welcome!
This question is subjective by nature, but I am curious about a specific thing, so hopefully there is a decent answer.
I tend to be a little old fashioned and like to create all my pages static and get the design just the way I like it (or at least very close) before I start breaking it down into handlebars and components and templates. This is mostly because the Ember "Getting Started" Guide taught me that process.
Is this the common practice, generally?
I am the front-end Designer and Developer for my company, and basically I have two separate workflows, one for Design, and one for Development/Testing.
Is there a way to merge the two and get a single streamlined workflow (perhaps a JS task that can split up static pages into templates by using some special markup??)
Design tends to be a little easier when you are working with static pages.
Development (especially when using EAK or Ember-CLI) expects everything to be modular and dynamic.
Is there any clear answer to this question?
I posted a similar question on Ember Forums, but have not gotten many view, so I figured I would try here.
Short answer when you're building an app with Ember you want to build around the URL structure, due to the way the URL and Router interact. Here's an awesome talk by Tom Dale about the URL. This makes it a very outside in approach, since each layer deeper in the url is content that's generally embedded 1 level deeper in the page.
http://vimeo.com/68390483
Just in my reading over the last few days I've found at least three different extensions offering data store support for Ember: ember-data, sproutcore-datastore, ember-ezdata, and I think I might be missing one.
This range of options gives rise to several questions.
Obviously ember-data is the "official" extension, but it's also pretty heavily fenced with qualifications ("This isn't ready for production") from the core team.
How should I compare and evaluate these options?
In the SproutCore 1.x series, development was usually done with fixtures, and the data source wired in later. Can any of these options support that sort of workflow? Can I load some production data this way (might change with release versions, but not user-editable) and other data from my back-end data source?
ETA: Here's a related question.
Personally, I'm expecting big things from ember-data, but it does seem to have a little way to go to be "production ready".
When I started using Ember, the ember-data project had just begun, so I decided to create a simple persistence layer of my own. I ended up with ember-rest, which is a pretty thin layer over jQuery.ajax(). You can see it in use in this Rails example. By the way, you can load JSON data directly into ember-rest without hooking into a backend.
I'm under the impression that sproutcore-datastore is no longer maintained. I've never tried ember-ezdata.
Another worthwhile option to check out is ember-resource.
I hope this is enough to get you started.
With the move from SproutCore 2.0 to EmberJS there was the namespace and Github repo migration. Core things seem to have moved to the http://github.com/emberjs organization Github account while there are some others that seem to have been moved to the "addons" account http://github.com/emberjs-addons.
I am currently investigating EmberJS for use with a RESTful server, serving up JSON.
My question is: Do I use the new http://github.com/emberjs/data code or the older http://github.com/emberjs-addons/sproutcore-datastore code? I would assume the former but I would just like to be sure as well as get some clarification on what is going on with the old SproutCore "addons".
The emberjs-addons are ports from the old sproutcore ecosystem. They are not modified and it looks like they are not receiving much attention from the emberjs core-team. They are concentrating on the new "emberjs-data". However, the old datastore is production proven and the modified version does work fine with the current emberjs relase (0.9.3).
In contrast, while the rewritten version looks really nice, it is explicitly stated in the projects readme that it is not considered "production ready", yet.
Which one should you choose? In my opinion that depends on your project. If you are looking for something stable or you want to put your app in production any time soon, I would give the "old" sproutcore datastore a go. On the other hand, if you are just starting with your project use the new and shiny "emberjs-data" but be warned that you might have to fight around some edges.
I have been using ember-models with my own REST adapter while I am waiting for the ember-models one to be completed. git://github.com/ebryn/ember-model.git