CODEWITHSUNDEEP
phpjavascriptrestyiiember.js
Asgaroth
Asgaroth

Reputation: 4334

Emberjs, server side vs client side, All in?

I have been looking into Ember.js, and it looks really great, but one thing that concerns me, and that I can't get my mind around it, is if I start using it on an already running project.

Will I eventually have to move everything client side, and make my application a single page application at some point?

let me clarify...

So far the best way to communicate between client and server using Ember is REST. and that looks great, but what I don't like is having all the templates loaded for the first time. and moving all the logic in my server to the client (or am I getting all of this wrong?), cause it looks like my server side will become a logic-less REST API.

Also, I'm using Yii Framework which has some JavaScript (Ajax enabled) components like grids. how can I have ember interact with all of this on navigation without having to rewrite a bunch of stuff already working on my application?

I'm on the login page (or state), and then after login in, I have to display a grid, that is just easy with Yii, and a full page load, but If I am using Ember, how can I have my grid display as it normally would? do I have to pre-load a handlebar template for the grid, and also the JavaScript that controls it?

Upvotes: 23

Views: 2054

Answers (3)

DarkMukke
DarkMukke

Reputation: 2489

In my experience, you can just access the existing controllers and actions (by cli or http) with your serverside JS. I did the same with my existing app that integrated with node.js.

A benefit from this is that you can keep you exisitng code as a fallback for browsers not fully supporting your new implementations or for search bots who arent great with javascript in the first place.

I wrote the whole app in my models anyway, i mean data control etc, the actual functionality is in commands. And if the browser is not supported or disables javascript, everything falls back to the normal way with anchors and page loads, using the UrlManager and actual controllers and actions. An those controllers an action simple call the commands. Ofcourse with a helper converting the json output to usable data for the views.

And the page load is with default php and controllers views anyway since it is already there.

Upvotes: 2

Imre L
Imre L

Reputation: 6249

No, you should not move everything to client side, especially authentication and validation that could be bypassed otherwise.

What you move to Emberjs is the yii-s View part of MVC, controller will output i.e JSON.

That Data then gets mapped to Embers Model part through Ember routing and controllers etc.

Since you are replacing Yii's presentation logic with ember you should not use Yii's UI classes like CGridView. Mixing them might be possible but that does not seem like a good idea. You have to run your own in Ember.

http://www.yiiframework.com/wiki/409/ember-js-with-yii-rest-backend-demo-application/

Upvotes: 10

Paystey
Paystey

Reputation: 3242

Just to add a Yii perspective here. A lot of the "magic" of grid views/lists happens within the data provider (for complex searching, sorting and filtering) and by having the data formatted with parsed fields on models.

So you could utilise the same concepts server side and just output the final JSON, paginated and all, from within your own widget; or even just override the grid view and output json rather than the view after all the data/configuration processing.

Once you've got JSON down rather than HTML it's very easy to replicate the front end of the grid, there's really not much functionality going on there.

This might not be ideal, but it means you don't have to move all logic for pagination, searching and filtering to client side.

TL;DR;
Override the Yii widgets which you already have functionality built for, and use them to output JSON rather than HTML.

Upvotes: 7

Related Questions