Js Data Framework (Eg Ember) Integration

For those of you who know Ember (a Javascript data framework, for routings, data bindings etc), it seems to me that it would be good to integrate Ember into Yii in the same way that Ember Data can be integrated into Ruby on Rails.

I think the MVC structure of Yii, and the way widgets like CGridView work should make Ember an attractive proposition for Ajax-based applications (the widget renderers should be able to translate their logic into Handlebars templates fairly easily, and the Html5 history API routing integration could stick quite nicely with Yii’s path routing model.

Again, I have just thrown this out there for discussion, without actually doing all necessary research as to whether it would be technically feasible, so please let me have your thoughts.

Why not AngularJS or Knockout or backbone?

I prefer Backbone.js myself, as Ember seems to be over-engineered. But… the good news is that this is not really something Yii can help with, much.

And it shouldn’t interfere with the front-end. It should stay out of that domain.

What Yii can do, is to serve JSON in a REST-like fashion, but Yii can do this today already.

See this: https://github.com/c...ech/YiiBackbone

No particular reason - all are valid - I did say “eg”. It’s just that Ember is the only one I have any real experience with, and (I may be wrong here - like I say, I don’t really know them) it seems to me that Backbone doesn’t include live templates, and Angular makes great use of element markup, while I quite like the idea in Ember of keeping data out of the Html (that being said - this is Html5 now, with support for data in tags…).

@jacmoe

As for Yii not interfering with the front-end, I do take the point, but Yii already does interfere with the front-end through things like the (very useful) widgets CListView/CGridView, which produce a similar effect (including Html5 history API routing to a limited extent) but without the structure and extensibility of things like Ember - so why not integrate that instead of the custom JS we use currently. And since these widgets are not actually part of the core anyway, we can say that it’s not interfering

While Ember may be over-engineered, the example you gave includes a fairly hefty amount of backbone plugins, that probably make it just as engineered as Ember.

Anyway, like I said - just throwing this out for discussion…

The Ember team assumes a lot, that’s my main gripe with it. We, the end-user developers need to follow their conventions.

Backbone, on the other hand, is much lighter, and leaves us with a lot more freedom.

As for grids, I won’t use what Yii provides. I’d use Backgrid instead:

http://wyuenho.github.com/backgrid/#examples

The grid in Yii is just an optional plugin, by means of Zii. I think it would be more trouble than it’s worth trying to make it work with Backbone.

All we need Yii for is to spit out some JSON.

Spitting out JSON is not too hard, but what I like about CGridView is the way that (mostly) it fails gracefully in case of JS problems - eg the sorting link on a column will work as a hard link if the click event is not triggered properly.

I’m probably not thinking about this deeply enough (my head hurts from work at the moment), but a Yii controller whose default view could implement an Html page with an Ember controller, generating routes that follow the same convention, using the history API so that the url functions as a proper route whatever the circumstances (js or no) sounds like something good to me…

I did (and still do) find Ember a steep learning curve, all the more so since they have made major breaking changes, so that most of the examples around are obsolete, but I think their philosophy is the same as the Ruby-on-Rails convention over configuration, and if I recall correctly, Yii is inspired from R-o-R.

Anyway, I’m going to give my head a rest…

You can’t expect a JS front-end library to work when a user has turned JS off. Think about it.

I heard a lot of good things of AngularJS, compared to Ember and Backbone. I think the AngularJS code is very clear.

Anyone who’s deciding for themselves which JS MVC framework they want, check out this site. They have made a TODO application for all major JS frameworks:

http://addyosmani.github.com/todomvc/

I don’t think we’ll support one particular library because it’s not very useful for most of non-application type of websites where there’s not much interactive stuff.

I wouldn’t expect that, but what I would like is for a front-end generated history url to work appropriately on a page refresh when js is disabled (so if I have a front-end page generated at mysite.com/posts, which lets me view a particular post, while changing the history url to mysite.com/posts/76 to represent its state, if I were to refresh that url without js enabled - or copy and paste the url into a browser without js enabled, then the back-end should generate the same representation as was used by the front-end controller with js enabled) - that is what would be advantageous about back-end/front-end integration.