Rails - Jul 2008 - Developing a RIA with ExtJS and Rails - the best way

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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jul 16, 10:52 am, "Marcelo de Moraes Serpa"
<celose...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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?


On Thu, Jul 17, 2008 at 4:27 AM, Peter De Berdt
<peter.de.berdt-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
wrote:
>
> 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
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.


Best regards

Peter De Berdt


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On Fri, Jul 18, 2008 at 4:53 AM, Peter De Berdt
<peter.de.berdt-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
wrote:
>
> 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.
>
>
> Best regards
>
>
> Peter De Berdt
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

keep it simple

http://juggernaut.rubyforge.org

On Jul 19, 11:18 am, Peter De Berdt
<peter.de.be...-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
wrote:
> > 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On 20 Jul 2008, at 08:56, Darkside wrote:
> keep it simple
>
> http://juggernaut.rubyforge.org
>
> On Jul 19, 11:18 am, Peter De Berdt
<peter.de.be...-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org> wrote:
>>> 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?
Best regards

Peter De Berdt


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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/.