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.
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 would like to use ember-data in a project I am building, but the API I am working with does not follow REST conventions.
For example, all the HTTP requests are POST and the naming conventions of the endpoints are unique to the actions they perform. e.g. /api/thing/retrieve would require me to post a JSON object with some parameters, and would return a 'thing' to me.
Do I use the Restful adapter and reopen the class and redefine the various find functions?
OR
Do I have to make a new adapter?
OR
Should I just abandon ember-data and and use ajax in my models(or maybe even controllers)?
I'm not sure how I would handle any of those options. Any guidance would be appreciated.
The only information which I have seen on this subject has been an article by the Discourse folks linked below.
http://eviltrout.com/2013/03/23/ember-without-data.html
I personally have toyed around with the reopenClass method in the article, and would probably drop it into a mixin or something to that effect if I had a consistent but non-REST API which I was calling regularly.
I would say that, if your API is consistent (reliable) then you should create/extend the DS.Adapter (not DS.RESTAdapter) to implement to your specification.
All the hooks are there, you will just end up defining it once which all models can use.
I would also read through the Basic Adapter code - (https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/basic_adapter.js) it might be a better staring point for you then DS.Adapter.
If your API is not reliable, then you are probably better off with just using the $.ajax() calls as necessary. But, in my opinion, that does not scale well.
A link worth reading when looking at Basic Adapter: http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.html
One last note, building an ORM or even a something more simple then an ORM is not a trivial task, that for me, makes using ember-data worth the effort, and yes sometimes pain.
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 :)
I am trying to understand the best practices for structuring an ember.js application. This slide from tomdale:
https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55
has a concise description of how to apportion the application logic. However in trying to follow these guidelines I have finding some problems:
The router is growing too large. According to the presentation the router "responds to events from views", but this results in a lot of code when there are dozens of views.
There are a huge number of controllers. In a Rails application the CRUD actions typically reside in the same controller, however for ember apps it seems that there should be a one controller to list records, one to view a record, one to create a record, etc.
It doesn't feel very DRY because I am ending up with so many files between the controllers, views and handlebars templates that each only have a couple of lines of code.
I am trying to decide if the problem is that I am applying the guidelines incorrectly, or whether these guidelines only work for trivial applications.
Does anyone have any advice - especially on how to manage the growth of the router?
I think that saying Ember encourages too many controllers is like saying Javascript encourages too many functions. Yeah, you can go crazy with proliferation of either. Or you can do the opposite, and have it work exactly as you need. In general, always remember that your app should be exactly as complex as it needs to be, and no more so. You don't need to use a certain architecture or pattern just because some famous coder guy used it, nor even because it seems to be 'the Ember way'. Even 'Universal Good Things' like Separation of Concerns, MVC, etc. are principles & models which you should try to understand fully then use to the extent that they serve your needs. I think that the ability to selectively break rules and patterns for the right reasons is far more telling a sign of a great hacker than slavish devotion to the dogma of the programming gods. This is a craft, not a religion. (But YMMV. Perhaps there's a special circle of hell reserved for coders like me. I'm betting against it.)
Specific to Ember, I tend to use Controllers around my data models and/or around a particular user workflow, rather than around each view. Then use Routing/State Managers as the glue between your views, and I generally use Event Managers on views to handle browser events within each view, including sending instructions to the router. So, if I have an app that revolves around, say, Customers and Products, I'll have a controller for each, just as I tend to do in Rails. This will result in each controller holding more functions and computed properties than some people like to have in one place. It also means that I can't necessarily reuse my views in another context, because they're hard-wired to the controller. And yes, this is poor Separation of Concerns. But that's not an absolute good if it causes complexity that has no payoff.
Also on the subject of Controllers, I think folks particularly tend to proliferate controllers unnecessarily for subsets of your main data model. Say you've got a products controller, and you want to store the products that a given user is collecting in a comparison tool. Most people seem to create a new controller for this, but it's perfectly legit to push these into an additional array or other Enumerable inside of your Products controller or Customers controller, or on your Customer model. This keeps objects that rely on the same functions and properties within a closer scope. The content object in each controller is, AFAIK, just another Enumerable. It has a few special implicit references to the Controller, but isn't magic. There's no functional reason I've found not to use additional ones too. They work just as well with bindings, with #each, etc.
Similarly, some people just LOOOVE to break their app down into a million files, nest them 15 deep in the file structure, etc. More power to you, if that helps you to visualize the underlying logic, and make it clear to the rest of your team. For me, it just slows me down on projects with only a 1-3 person engineering team. Folks also tend to reproduce the file-based style of other MVC systems they're familiar with (like Rails), where files are the necessary explicit structure for separating views and other logic objects. This becomes an article of faith and a deeply ingrained habit. But in Javascript MVC, I have found that it often serves no such purpose and is strictly redundant to the implicit design. I tend to use a single, carefully organized file for my entire Ember app (separating it from any other non-library JS), with lots of indentation and nesting where that helps me to visualize the hierarchy. Whatever you do, file-wise, it's all the same at runtime, provided that you deliver it all to the right place at the right time. With Ember and JS, file structure is for the needs of your team, and nothing else. Calibrate accordingly.
(IMPORTANT CAVEAT: if you do use a million files, you'd better be using a pre-compiler to manifest them all together for delivery to the user, or you're going to take a huge latency hit on delivering all those files separately.)
(ANOTHER IMPORTANT CAVEAT: with a large team or a rapid daily release schedule like GitHub's, file-based separation of your logic can make version-control easier than doing lots of merges into the same file, where your merge tool may get confused. Again, this is an issue of managing and monitoring your human processes, and doing merges carefully, rather than a technical requirement imposed by your JS framework.)
(LAST IMPORTANT CAVEAT: Then again, sometimes the difference between a technical requirement and a human/procedural requirement is fuzzy. If you break your developer's brain, you also tend to have a broken app. So, do what works for the people and processes you have to deal with in getting it built.)
As I said before, YMMV. I'm not a coder God, as you can tell from my reputation score, so you may feel free to disregard me. But I stand behind the idea that you should use only as much complexity, only as much file-structure, and only as many higher-level abstractions (like routing, which may actually be overkill for limited-purpose single-page apps) as serves your needs; and no more.
I think we are developing a quite large ember app (about 45 views at the moment). It implies almost the same count of controllers and templates).
Indeed our router is quite large, but we manage it quite easily by splitting it into many files. Basically, each file represent one screen of the app and is responsible for maintaining a functional set. Here is an extract of the router:
Router = Ember.Router.extend({
root: Ember.Route.extend({
index: Ember.Route.extend({
route: '/',
unlogged: Ember.Route.extend({
route: 'welcome',
connectOutlets: function (router) {
var applicationController = router.get('applicationController');
applicationController.connectOutlet('welcome');
}
}),
logged: Ember.Route.extend({
route: 'app',
projects: Ember.Route.extend({
route: 'projects',
collection: ProjectsRoute,
member: ProjectRoute,
showProjects: function (router) {
router.transitionTo('projects.collection');
}
})
})
})
Then it the same in the ProjectRoute. Each time there seems to have to many feature in one route, we split it.
You can even reopen a route to extend it, and to plug other functionnality in it.
ProjectState.reopen({
scenarios: ScenariosRoute,
showScenarios: function (router) {
router.transitionTo('scenarios.collection');
}
});
It implies more files, but with a good organization, it's no hard to maintain, as it's very rare you work on all features at the same time. Usually, I have nore more 4 opened files simultaneously (view, controller, template, route)
I don't know if it's a best practice, but it works pretty fine for us
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.