I've been trying to rework an as yet unfinished ember app of mine to use require.js
It's mainly for interest value and I started looking into it when I wanted to use require-text for my handlebar templates, for convenience. So I havent found myself looking into it for any sort of AMD related performance win or anything like that. But now I've started setting my module out by defining modules I am finding it easier to read and would like to stick with it.
There is a question on stack overflow where the asked has come back and posted their findings Ember.js and RequireJS but none of the other examples, like the example on todo MVC can be found on references on how to optimally structure and reference the files in more complex apps.
So anyway, my question is: What are the rules to follow to make correct use of require JS. What does it achieve (apart from access to AMD)? It's hard for me to get my head around it with a test project that doesnt really require it, but I'd like to learn the correct ember related principles so I can use it in future.
I've seen from example code that the idea may be to remove all references to the global namespaces from the modules. Is that correct? There arent enough examples around for me to spot a pattern.
At the moment a file at the top level of my structure might have some stuff like this in
<script>
define(['jquery',
'app/controllers/mailshotlist',
'app/controllers/sites',
'ember'],
function($, MailShotList, Sites) {
var App = Em.Application.create({
Views: Em.Namespace.create(),
Models: Em.Namespace.create(),
Controllers: Em.Namespace.create(),
init: function() {
this._super();
this.Controllers.set('Sites',Sites.create());
this.Controllers.set('MailShotList',MailShotList.create({
sitesControllerBinding: 'App.Controllers.Sites'
}));
}
});
return window.App = App;
});
</script>
So, trying to stitch together explicit app.x references in initialisation of the app. Since I guess if your modules are all referencing each other explicitly in the code then its not properly modular. I'm not at the stage where i want to reuse modules at the moment, but im assuming that is one of the goals
I'd like for this not to turn into a debate about whether AMD is worth it or not, my question is specifically about what rules need to be followed to get the most out of using ember with require js. Although if there are good specific reasons for not using ember with require then that would be interesting.
I think I've rambled a bit and am running the risk of getting this locked as 'non-productive' but If you can understand my question and what im trying to understand (or if im barking up the wrong tree entirely) then please post a reply
Haven't made up my own opinion yet but this is what Ember.js developer Tom Dale has to say on the matter.
http://tomdale.net/2012/01/amd-is-not-the-answer/
If you still want to use EmberJS and RequireJS,
I've just uploaded to github a starter-kit for EmberJS+RequireJS, You could check it https://github.com/fernandogmar/Emberjs-RequireJS
It's my particular suggestion for big enough projects...
Any good suggestions will be highly appreciated. Have Fun!
There is nothing that makes emberjs / requirejs relationship special , they are orthogonal. Does Ember solves dependencies between script files ? no , Is requirejs a MVC framework ? no , so what is the problem ? The use of requirejs with emberjs is no different from the use of requirejs with any library that doesnt provide AMD. So nothing special here. You want AMD ? use requirejs to define your own modules and resolve dependancies between them , that's the point.
The only question is , do you have a problem to solve or not ?
As #mpm wrote, there is nothing special about Ember.js + RequireJS or other no-AMD framework + RequireJS.
Good starting point is RequireJS documentation and Ember.js + RequireJS TodoMVC project example:
http://requirejs.org/docs/start.html
http://addyosmani.github.com/todomvc/
Related
I'm making an essay about AngularJS vs EmberJS. In here I compare these two with different questions and at the end a decision is made for which one is better for developing web applications based on the answers of these questions.
One question that I have struggled with for EmberJS is about maintainability. I haven't been able to find one article that gives information about this, unlike AngularJS.
I would like to know how does EmberJS helps you maintain your EmberJS web application. What concepts or whatever, does it provide to help you achieve a high level of maintainability for your web applications build with EmberJS.
Thank you for any help regarding answering this question.
How does Ember help you maintain your application?
Some of this is subjective/debatable, but in the spirit of essays, here are some points for Ember in terms of maintainability:
Because Ember is so highly opinionated, it makes it really easy for other Ember developers to understand your project quickly and pick up where you left off. While the framework has a pretty infamous learning curve, once you're comfortable with Ember, most applications share a lot of similarities. Ember has a prescribed 'way' for doing most things -- from file structure to REST api interaction. If you've worked on one Ember project, moving in to do maintenance on another should feel very familiar. It's a big, standardized toolbox.
The Ember Inspector browser plugin gives you a lot of transparency into what's going on beneath the hood of your application. It's very helpful to debug and maintain Ember apps. I haven't really seen anything yet that's quite the same for other frameworks. (https://chrome.google.com/webstore/detail/ember-inspector/bmdblncegkenkacieihfhpjfppoconhi?hl=en)
Ember's handlebars templates don't allow you to put complex logic in your template. Any "if" check in a template must refer to a boolean value. This means less places to look to track down what you need to work on, and more testing of raw functions because your view isn't handling more than basic logic. It also encourages more readable templates.
Ember comes with built-in tooling for unit tests, integration tests, and end-to-end tests. This encourages devs to build tests for their applications or contribute to the existing tests of a project. Tests are good for maintainability.
Good luck!
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 ...
This is more of an exploration question.
We have been using breeze.js in our projects for a while and have been quite satisfied with it; it ties nicely into concepts we already know and use (change tracking, metadata, backend agnostic...)
Now we are evaluating the possibility to move our front-end from backbone/marionette/knockout stack to ember.js (which seems to be more of a complete framework than a "pick-only-what-you-need" approach in backbone). We are exploring to possibility to keep using breeze.js as our data management layer on the client-front.
But how can the integration of models returned from the server (server stack: node.js + mongoDB) be done with models defined by ember.js?
A typical ember model definition could be:
var Person = Ember.Object.extend({
Property1: 'foo',
Property2: 'bar'
});
where you can see the extension "Ember.Object.extend"
Breeze.js upon receiving data from server attach a AspectEntity to them (and if Knockout is defined, wrap properties in observables ). How could returned objects somehow be "transformed" into ember.js objects?
Maybe the way we approach this problem and the way we think about this integration is totally wrong or that we should entirely reject this "ember-breeze" combo. From google search we have not found cases where breeze is used with ember.js or some guidance. That is why we come to the stackoverflow community: is it possible? what are the possible pitfalls to look ahead?
There does not seem to be much in the way of existing solutions. The Breeze.js User Voice has some 2-year-old issues that never got much traction; support from that library does not seem to be imminent.
I would recommend exploring Ember-Data as your data management layer. It supports many (if not all) of the concepts you mentioned, and it's the default recommended data library for Ember applications.
That said, as far as trying to make Breeze.js work, you could probably take the objects returned from Breeze and turn them into Ember.Objects using Ember.Object.create, but you'd have to build a layer between Breeze and Ember that essentially serializes between Breeze objects and Ember objects in both directions.
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
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 :)