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 ...
Related
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.
I have a lot of experience with AngularJS and I'm also playing around with Web Components and Polymer for a long time now.
What I really love about the these libraries and technologies, is the fact that they let me build my own components.
AngularJS gives me something called "Directives" and Web Components consists of a set of specs where one is called "Custom Elements", which pretty much does how it's called.
So with these I can do something like:
<my-element></my-element>
This is where the web goes, this is what everybody loves about HTML. Declarative tags that are easy to read and encapsulate functionality and behaviour. Also very nice: once Web Components are fully supported in the browsers, I could for example very easily remove my directive and rely on a web component, that looks and works the same without changing any code.
I know, that EmberJS has something called "Ember Components" which lets you basically build your own kind of components too. However, using them in HTML looks something like this:
{{#my-component}}
{{/my-component}}
Is it possible in EmberJS to also use components declaratively as tags?
I actually hate that about html. I hate the structure etc, but that's just my opinion :)
No, there isn't, your component should be declared in a template using the handlebars syntax, and compiled to js. (you can dynamically create views/components, but that's far from declarative tags).
You'll be able to do that when Glimmer 2 ships with Ember. It was supposed to be in with Ember 2.x, but for some reason its still pending. With that you can use angle brackets to define components.
<my-element></my-element>
I need to take the results of a web service and display them in a front-end component view. I am returning the results and they are in JSON format but am not sure how the component should be built. I don't need a debate on the best way, just some advice on a good way to built this as a component i will be able to install on multiple Joomla 3 instances.
Once thing that would help greatly is some direction on where to place the code that consumes the web service. Would that be a component model? Or better as a library sitting outside the component?
Thanks
Seems like you need some fast solution before learning the MVC architecture in Joomla!3 so probably a good suggestion would be to build a sample component at http://www.component-creator.com/home and then work and learn from there.
Then for the code for the webservices, it depends on what you want to do with the code, but if it's just to render in the view as you get it, use the view.html.php in your component views directory. Then, in your tmpl default view use the data to render as required.
Further you can create your own methods on the models or controllers in case you need to do something with the data, but before that, try to understand the Joomla! 3 main MVC architecture principles ;)
I'm trying to optimize my company's application.
Tha architecture at this time is composed of different folders (inside common folder) for different sections of the app (for example Managing Bills, Managing Canteen, Managing Events etc etc).
Every js and css are included in the first page of the application (login.html) because I'm using the simple page template of jQuery Mobile.
Now I'm considering to add some other components to make the app easier to mantain and maybe speed it a bit.
What do you think about:
RequireJS to divide each section in a module so i can load only the javascript of a particular module at run-time instead of loading within login.html
Inline #imports for CSS files to produce single composite CSS
uglify.js to Minimize file sizes
Handlebars.js to realize fragments of html reusable
Do you think is a good way of work for an application that will become greater by adding new sections?
Do you think of other tools?
Thank you
This is a very broad question. I think you're on the right track... I'll list some libraries that could be worth trying:
Require.js - Will give you the ability to have 'modules' and dynamically determine and load dependancies. Alternatively some people prefer patterns such as the Revealing Module Pattern, jQuery Plugin Style or Common JS style modules. For what it's worth I recommend Require.js.
Bower is a package manager, you can use it to bower install [package]. They have a lot of packages here and you can also link it to your own repo. This could be helpful for managing dependancies.
Uglify.js and Google Closure Compiler are both good for minifying your code. Remember that some minification configurations such as advance mode could break your code. Run tests against the minified version of your source code.
QUnit is good for doing JavaScript unit tests. There are many other alternatives like Jasmine, which is what the Cordova guys use.
Lodash is another (faster) implementation of underscore.js that will provide a lot of utility methods for working wit arrays, objects, functions, etc. It also includes templating support. There's a good talk by the author here.
There a MV* JavaScript frameworks that could help more than jQuery (DOM+AJAX+Animations) or jQuery Mobile (Mostly UI) such as: Dojo, AngularJS, Backbone and Ember.js.
For UI you may want to checkout Adobe's topcoat repository and website. There's also Twitter Bootstrap and Foundation which allow you do to responsive design out of the box. If you're set on jQuery Mobile I personally like this Flat theme.
JSDoc and YUIDoc are good alternatives for documenting your JavaScript code.
I have no idea how many of those tools will interact inside Worklight Applications. It should be fine, since Worklight doesn't impose a certain set of JavaScript libraries you have to use. However, I haven't personally tried most of them inside Worklight Applications.
I can understand needing some abstraction layer for common operations like retrieving DOM elements, attribute manipulation, etc., but jQuery is a pretty massive library that seems like a lot of overkill for Ember.
After looking through the source code, there are only about 30 or so uses of jQuery in Ember and it looks like the majority of jQuery usage is simple selector calls, some events, and some DOM traversal.
Ember.$(rootElement).off('.ember', '**').removeClass('ember-application');
...
elem = this.$();
...
this.$().appendTo(target);
...
Ember.$(window).on('hashchange.ember-location-'+guid, function() {
etc.
Are there any other reasons Ember requires jQuery for every application?
Could these few uses be embedded into Ember and jQuery removed as a dependency?
The question was extremely well explained by Tom Dale (Ember Core Developer).
Essentially he says:
Ember.js requires jQuery for two reasons:
We rely on it heavily in the Ember/Handlebars integration for inserting and modifying DOM elements. I personally am not interested
in dealing with cross-browser DOM manipulation bugs, but the jQuery
team excels at it.
By having a standard DOM manipulation library in jQuery, developers can move between different Ember.js apps and rely on the fact that
they have a battle-tested, cross-platform library underneath them.
If you are concerned about size, I'd recommend investigating the new
jQuery 2.0, which has the ability to do custom builds without features
such as animation.
Makes a lot of sense to me.
Update:
Recently Erik Bryn (Ember Core Developer too) wrote a very interesting comment about the framework and mentioned the state of the art of jQuery usage in Ember projects.
Pasting the comment:
It's a common misconception that Ember.js is monolithic. I can assure
you that isn't actually true. You can pick and choose the parts of
Ember that you want or need (for example, the router is totally
optional). Our build tools even support picking and choosing which
packages you want. You can use it today without jQuery (you will need
to shim and have an event delegation library, or even easier use a
super-lightweight custom jQuery build).
Only Ember's view layer depends on jQuery. It was used more heavily historically than it is now. In the future, we could as you suggest, roll functionality into Ember itself, although we do not want to maintain cross-browser compatibility in Ember that jQuery is already taking care of. Another path, with jQuery 2.0, would be a way to create trimmer build of jQuery containing just the portions that Ember uses.
If there are no-compromise ways to replace instances of jQuery usage in Ember core, you should propose the changes as issues on GitHub.