Developing a RIA with ExtJS and Rails - the best way

[Marcelo de Moraes Serpa]

Hello list,

I'm developing an application in Rails and I'm using Extjs 2 for GUI/presentation stuff.

I've found some plugins and helpers that claimed to solve some of the issues on Extjs and Rails integration. However, high-level frameworks like ExtJs are better programmed using the "Proxy" Ajax-style (term coined by Edward Benson on his excellent "The Art Of Rails" book). In this Ajax style, the server is has most of business-rules implemented and the client, implemented in Javascript/HTML/CSS can also have some business rules but mostly applied to the presentation of the data. However, it's like there are two application, the client and the server, and the client can, in theory, live without the server or use another backend, something that doesn't happen with the "Partial" and "Puppet" styles, where compiled RJS and partials are sent back to the client.

The following page talks about using Extjs with Rails: http://inside.glnetworks.de/2008/01/08/ext-js-and-rails-how-do-they-get-along/

It even provides a link to a plugin that provides a scaffold generator and extends ActiveRecord::Base to provide a helper method to generate ExtJs-compatible json.

But from what I could understand, the author only views ExtJs as a cool GUI for CRUD views. He does mention RIAs, but I didn't see any mention of techniques to really develop RIAs with Extjs and Rails. His approach is useful only if you want fancier CRUD views or eventually use some of the ExtJS widgets in parts of your website/web app. Please, someone correct me if mu judgment happens to be wrong.

So, the main question is: What would be the best way to develop a RIA with Rails and ExtJS while still getting the most of out of Rails (RESTful design, testing, excellent maintabilty) and also from ExtJS (desktop-like experience, no page reloads)?

My opinion is: Unless ExtJs gets completely abstracted in Ruby/Rails (something that Ext GWT did for Java/GWT), if you really want to benefit from ExtJs for Rich Internet Applications, you will have to shift your mindset and don't treat Rails as the central toolbox/ "cockpit" for the application. You will have to get your hands dirty and write JavaScript in separate JS and HTML files. Rails would then serve the necessary data via JSON. I don't see also any use for Rails views here.

Please, share your opinions and experiences!

Thanks,

Marcelo.

[Allan]

On Jul 16, 10:52 am, "Marcelo de Moraes Serpa" <celose...@gmail.com>
wrote:

> My opinion is: Unless ExtJs gets completely abstracted in Ruby/Rails
> (something that Ext GWT did for Java/GWT), if you really want to benefit
> from ExtJs for Rich Internet Applications, you will have to shift your
> mindset and don't treat Rails as the central toolbox/ "cockpit" for the
> application. You will have to get your hands dirty and write JavaScript in
> separate JS and HTML files. Rails would then serve the necessary data via
> JSON. I don't see also any use for Rails views here.
>
> Please, share your opinions and experiences!

Hi,

I agree that you do have to throw away much of the view stuff that
Rails provides and concentrate far more on RESTful design, which means
more focus on parameters in the 7 or so basic actions or a more
complex routing set up to handle all the new actions and map them to
model actions.

JavaScript is much harder to debug, Firefox being the only viable
option IMHO.

Allan

[Peter De Berdt]

On 16 Jul 2008, at 17:52, Marcelo de Moraes Serpa wrote:

So, the main question is: What would be the best way to develop a RIA with Rails and ExtJS while still getting the most of out of Rails (RESTful design, testing, excellent maintabilty) and also from ExtJS (desktop-like experience, no page reloads)?

My opinion is: Unless ExtJs gets completely abstracted in Ruby/Rails (something that Ext GWT did for Java/GWT), if you really want to benefit from ExtJs for Rich Internet Applications, you will have to shift your mindset and don't treat Rails as the central toolbox/ "cockpit" for the application. You will have to get your hands dirty and write JavaScript in separate JS and HTML files. Rails would then serve the necessary data via JSON. I don't see also any use for Rails views here.

Exactly, if you want to develop an RIA with something like ExtJS or SproutCore, you create the frontend in ExtJS/Sproutcore code and use Rails purely as a way of serving and handling data. That doesn't mean Rails is less important to your application, it only means you won't be doing your views in Rails for the most part.

Best regards

Peter De Berdt

[Marcelo de Moraes Serpa]

Hello Peter!
 

Exactly, if you want to develop an RIA with something like ExtJS or SproutCore, you create the frontend in ExtJS/Sproutcore code and use Rails purely as a way of serving and handling data. That doesn't mean Rails is less important to your application, it only means you won't be doing your views in Rails for the most part.

Yeah, this is exactly where the main question is: Should you use ERB and Rails/Ruby to help you assemble your ExtJS front-end code?

That is where I'm still confused. I don't know yet if I should treat Rails as a black-box data-only back-end, or if I should generate my ExtJS code from Rails. I can see advantages of doing it from Rails, as you can abstract some concepts as needed and make things simpler. Also, deep integration is easy, if needed (such as writing data directly into scripts/html etc).

However, I've seen in many places and even in the book "Practical Rails Projects" that ExtJS is used for its widgets and layout capabilities. Ok, that's fair, but the authors don't really develop a RIA. There is still complete page reloads which implies in complete ExtJS reload too. That's definetly not RIA but an enhanced Ajax experience only.

What I want to do is serve a RIA, Flex-like. However, I want to do it the best way. I can see many security problems if you end up exposing too much of your application on the client side, too.

I think I will go developing a PagesController, make an index action, configure the application layout to include the ExtJS JS files, and make the whole RIA in this index.rhtml template. This way, I can compartimentize other views as rhtml or rjs templates, if needed - even though I can't really think of a good reason to pre-process them other than hiding it from the public webserver and controlling access to it, which can be a good thing, of course. Then, I can also write static JS files as needed and put them in the public dir.

This way I would have the best of both worlds, and could use ruby to abstract some ExtJS concepts if I ever feel the need to.

What do you think?

[Peter De Berdt]

On 17 Jul 2008, at 16:30, Marcelo de Moraes Serpa wrote:

Exactly, if you want to develop an RIA with something like ExtJS or SproutCore, you create the frontend in ExtJS/Sproutcore code and use Rails purely as a way of serving and handling data. That doesn't mean Rails is less important to your application, it only means you won't be doing your views in Rails for the most part.

Yeah, this is exactly where the main question is: Should you use ERB and Rails/Ruby to help you assemble your ExtJS front-end code?

That is where I'm still confused. I don't know yet if I should treat Rails as a black-box data-only back-end, or if I should generate my ExtJS code from Rails. I can see advantages of doing it from Rails, as you can abstract some concepts as needed and make things simpler. Also, deep integration is easy, if needed (such as writing data directly into scripts/html etc). 

However, I've seen in many places and even in the book "Practical Rails Projects" that ExtJS is used for its widgets and layout capabilities. Ok, that's fair, but the authors don't really develop a RIA. There is still complete page reloads which implies in complete ExtJS reload too. That's definetly not RIA but an enhanced Ajax experience only.

What I want to do is serve a RIA, Flex-like. However, I want to do it the best way. I can see many security problems if you end up exposing too much of your application on the client side, too. 

I think I will go developing a PagesController, make an index action, configure the application layout to include the ExtJS JS files, and make the whole RIA in this index.rhtml template. This way, I can compartimentize other views as rhtml or rjs templates, if needed - even though I can't really think of a good reason to pre-process them other than hiding it from the public webserver and controlling access to it, which can be a good thing, of course. Then, I can also write static JS files as needed and put them in the public dir.

This way I would have the best of both worlds, and could use ruby to abstract some ExtJS concepts if I ever feel the need to. 

What do you think?

I would use Rails to assemble the pages, however... I would seriously advise you to dive into page caching and have apache (or nginx) serve up the cached pages. After all, an RIA starts off with defining a grid with no real dynamic data in it, it would be a terrible waste of CPU cycles to generate those pages over and over again.

The main reason why it's still interesting to use Rails for the initial page generation is its url generation. If you write everything in static JS files and you or Rails (like it did at a certain moment with rest_action;edit to rest_action/edit) decides to change the url generation scheme, you'll have to plow through all of the static code, not very pleasant. ExtJS in its latest version supports all of the REST verbs btw, but iirc it doesn't follow the same convention as Rails, you'll have to look into it.

A second reason to still use Rails for page generation, is the authenticity token. I'm going to save you the trouble of finding out how to do pass in the token on every AJAX request. Add the following code on top of your main layout (the one that is used on every single page):

    <script type="text/javascript" charset="utf-8">

        window._token = '<%= form_authenticity_token -%>';

    </script>

And then, assuming you'll still be using the prototype adapter to work with ExtJS, put this in the first javascript file that is loaded:

Ajax.Base.prototype.initialize = Ajax.Base.prototype.initialize.wrap(

  function(p, options){

    p(options);

    this.options.parameters = this.options.parameters || {};

    this.options.parameters.authenticity_token = window._token || '';

  }

);

And one word of warning about ExtJS: read up on the license, I don't know what it is right now, because it has been changed a number of times. Jack Slocum is trying to find a way to make his hard work pay off, but it's been hard on him (and a lot of dismay amongst the extjs users for it, although justified also unfair towards Jack).

I would be more tempted to use SproutCore for an RIA btw, it's syntax is a lot more rubyesque. It has less prechewed components to make use of, but it's a lot, and I mean a lot cleaner and browser friendly (in terms of memory use and event handling for example).

And although ExtJS has possibilities to work with Google Gears, SproutCore is the first RIA framework that makes offline web apps a breeze. And it has a nice future, with Apple being one of the big players putting its shoulders under the project.

[Marcelo de Moraes Serpa]

Thanks a lot for the comprehensive reply Peter!

I would use Rails to assemble the pages, however... I would seriously advise you to dive into page caching and have apache (or nginx) serve up the cached pages. After all, an RIA starts off with defining a grid with no real dynamic data in it, it would be a terrible waste of CPU cycles to generate those pages over and over again.

Yes, I thought it would be needed. Thanks for confirming it! But as a side note, I've seen in some places the following design pattern: People using Rails (or any other server-side language/framework) to write the javascript data-structures (generated from models) directly into the HTML in some cases. I think it is a bad thing to do, since it would complicate page caching that otherwise would be simple in this case.

The main reason why it's still interesting to use Rails for the initial page generation is its url generation. If you write everything in static JS files and you or Rails (like it did at a certain moment with rest_action;edit to rest_action/edit) decides to change the url generation scheme, you'll have to plow through all of the static code, not very pleasant. ExtJS in its latest version supports all of the REST verbs btw, but iirc it doesn't follow the same convention as Rails, you'll have to look into it.

You mean using the URL generation helper methods generated by map.resources to generate the URLS for ExtJS Ajax requests?

A second reason to still use Rails for page generation, is the authenticity token. I'm going to save you the trouble of finding out how to do pass in the token on every AJAX request. Add the following code on top of your main layout (the one that is used on every single page):

Thanks a lot for letting me know and also for providing the solution!

And one word of warning about ExtJS: read up on the license, I don't know what it is right now, because it has been changed a number of times. Jack Slocum is trying to find a way to make his hard work pay off, but it's been hard on him (and a lot of dismay amongst the extjs users for it, although justified also unfair towards Jack).

I'm aware of the license. I haven't bought it yet, but since my application will be commercial, I will (and am willing to) buy the developer license once I get the first production release ready. It is not expensive really for what you get IMHO.

I would be more tempted to use SproutCore for an RIA btw, it's syntax is a lot more rubyesque. It has less prechewed components to make use of, but it's a lot, and I mean a lot cleaner and browser friendly (in terms of memory use and event handling for example).

And although ExtJS has possibilities to work with Google Gears, SproutCore is the first RIA framework that makes offline web apps a breeze. And it has a nice future, with Apple being one of the big players putting its shoulders under the project.

I have taken a look at Sproutscore, and while it is a cool project, I was not very impressed by it after seeing ExtJS and its capabilities, and also found it to be slower than ExtJS perfomance-wise. ExtJS really brings a smooth desktop-like experience and saves tons of times with its well-designed widgets and overall architecture and in the end you have a beautiful and functional application that could have been said to be a desktop app or built on the Flash platform.


Thanks a lot for the help!

Marcelo.

[Peter De Berdt]

> The main reason why it's still interesting to use Rails for the
> initial page generation is its url generation. If you write
> everything in static JS files and you or Rails (like it did at a
> certain moment with rest_action;edit to rest_action/edit) decides to
> change the url generation scheme, you'll have to plow through all of
> the static code, not very pleasant. ExtJS in its latest version
> supports all of the REST verbs btw, but iirc it doesn't follow the
> same convention as Rails, you'll have to look into it.
>
> You mean using the URL generation helper methods generated by
> map.resources to generate the URLS for ExtJS Ajax requests?

Yes.

[Darkside]

keep it simple

http://juggernaut.rubyforge.org

[Peter De Berdt]

What does Juggernaut, a Flash based push server, have to do with url generation for RIA applications?

[Chris Scott]

Ext JS on Rails -- A Comprehensive Tutorial

Rendering Ext JS with traditional Rails views using a simple gem
extjs-mvc

http://www.extjs.com/blog/2009/09/30/ext-js-on-rails-a-comprehensivetutorial/
--
Posted via http://www.ruby-forum.com/.