Rails - Feb 2007 - RESTful Rails and other musings

Hi all,

I would first like to introduce myself to the Ruby on Rails (RoR)
community and to say that I hope to begin to build some relationships
with other RoR developers.

I''m a long time Java programmer (5+ years).  Java was my first
experience with Object Oriented Programming (OOP).  Before Java I
developed using many other languages including C, Pascal, Fortran,
BASIC, Visual Basic, and others.

I''ve only recently discovered Ruby on Rails and have been watching the
progress and trend toward a RESTful design.  I''d have to say
I''m more
that a bit intrigued by the concept.

At present my RoR work is for personal web sites, as I ramp up my
Rails and agile development skill sets, but I really want to start
things off the right way.

One of the key factors that caught my attention was the "convention
over configuration" philosophy behind the RoR design.  As a Java
developer I have often felt "weighed down" by the myriad of
configuration and design decisions that go into build a Java
application.
>From my first Ruby class implementation (an ActiveRecord subclass) I
was immediately struck by how much sense it all made.   The code on
the screen, was the code that was in my head.  From that point on I
was hooked.  And, that''s not to mention database migrations and
hundreds of other "cool factors" in Ruby and in Rails.

I have been living in a world without constraints, which sounds great
on the surface.  However, it''s a deceiving world with many technology
choices, leading to a proliferation of design inconsistencies, which
in turn lead to rigid and fragile application code.

Now on to the point of discussion I would like to present:

1. Assuming no legacy RoR code, being brand new to the framework, is
Rails 1.2.1 far enough along to embrace the new RESTful design
approach?

2. Can we expect scaffold generators that fully support the RESTful
controller design patterns?  Or, do these already exist in Rails
1.2.1?

3. Should we consider the "Postback Action" design pattern to be
deprecated when building RESTful Rails applications?

Excited to hear your thoughts,
Robert Walker
Software Developer
Atlanta, GA


--~--~---------~--~----~------------~-------~--~----~
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 2/1/07, GoodbyeJava
<rwalker348-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 1. Assuming no legacy RoR code, being brand new to the framework, is
> Rails 1.2.1 far enough along to embrace the new RESTful design
> approach?
Yep.  1.2 has support for restful routes.  The only thing it''s missing
is ActiveResource, which can be used to consume RESTful resources.

> 2. Can we expect scaffold generators that fully support the RESTful
> controller design patterns?  Or, do these already exist in Rails
> 1.2.1?
Already in there.  ./script/generate scaffold_resource
> 3. Should we consider the "Postback Action" design pattern to be
> deprecated when building RESTful Rails applications?
I''m not sure what you mean by this, to tell you the truth.

Pat

--~--~---------~--~----~------------~-------~--~----~
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 Feb 1, 2007, at 1:55 PM, Pat Maddox wrote:
>
> On 2/1/07, GoodbyeJava
<rwalker348-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> 3. Should we consider the "Postback Action" design pattern to
be
>> deprecated when building RESTful Rails applications?
>
> I''m not sure what you mean by this, to tell you the truth.
>
It''s not any more deprecated than it was before.  In other words, it  
was never really encouraged before, and it''s not really encouraged  
now, but you''re free to do it if you like.  You won''t be able
to use
the short-cut of map.resources, since it expects separate new/create  
and edit/update actions, but that''s the trade-off.

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

> > 3. Should we consider the "Postback Action" design pattern
to be
> > deprecated when building RESTful Rails applications?
>
> I''m not sure what you mean by this, to tell you the truth.
I was referring to this pattern from the "Rails Recipes" book:

def edit
  @recipe = Recipe.find_by_id(params[:id]) || Recipe.new
  if request.post?
    @recipe.attributes = params[:recipe]
    redirect_to :main_url and return if @recipe.save
  end
end

This pattern seems to be somewhat in conflict with the RESTful
controller patterns.


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

> def edit
>   @recipe = Recipe.find_by_id(params[:id]) || Recipe.new
>   if request.post?
>     @recipe.attributes = params[:recipe]
>     redirect_to :main_url and return if @recipe.save
>   end
> end
>
> This pattern seems to be somewhat in conflict with the RESTful
> controller patterns.
It''s not deprecated, nor discouraged by any means.  However, it
won''t
fit with the restful model.  Consider the code in scaffold_resource,
like the code in scaffold, a simple suggestion.

Hell, if you find yourself going with your own unique style, take one
of those generators and make a personal copy of it that spits it out
in the way you like :)

-- 
Rick Olson
http://weblog.techno-weenie.net
http://mephistoblog.com

--~--~---------~--~----~------------~-------~--~----~
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 Feb 1, 8:51 pm, "Rick Olson"
<technowee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > def edit
> >   @recipe = Recipe.find_by_id(params[:id]) || Recipe.new
> >   if request.post?
> >     @recipe.attributes = params[:recipe]
> >     redirect_to :main_url and return if @recipe.save
> >   end
> > end
>
> > This pattern seems to be somewhat in conflict with the RESTful
> > controller patterns.
>
> It''s not deprecated, nor discouraged by any means.  However, it
won''t
> fit with the restful model.  Consider the code in scaffold_resource,
> like the code in scaffold, a simple suggestion.
>
> Hell, if you find yourself going with your own unique style, take one
> of those generators and make a personal copy of it that spits it out
> in the way you like :)
>
> --
> Rick Olsonhttp://weblog.techno-weenie.nethttp://mephistoblog.com
Thanks for the clarification.  Just trying to get a feel for what more
experienced Rails programmers are doing.

I do have one question about the scaffold_resource generator though.
I started a new rails project to start experimenting and ran into
something I thought was a bit strange.  If you use the generator
before generating a model all seems to go pretty well.  It creates the
model for you and the scaffold and even adds the map.resources :users
to the routes.rb file.  But since it all happens at once there are no
fields in the migration so you get an empty form with just a submit
button.

So instead I tried creating the model first and filling out my
migration.  Then after running the scaffold_resources generator it get
up to the point it tries to create the migration and stops because the
migration exists already.

What am I doing wrong?

Thanks,
Robert


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

you can have the generator create the migration for you, ie:
./script/generate scaffold_resource post title:string created_on:date
body:text published:boolean

just run the generator w/out args to see some docs.

ed

On 2/1/07, Robert Walker
<rwalker348-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On Feb 1, 8:51 pm, "Rick Olson"
<technowee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > def edit
> > >   @recipe = Recipe.find_by_id(params[:id]) || Recipe.new
> > >   if request.post?
> > >     @recipe.attributes = params[:recipe]
> > >     redirect_to :main_url and return if @recipe.save
> > >   end
> > > end
> >
> > > This pattern seems to be somewhat in conflict with the RESTful
> > > controller patterns.
> >
> > It''s not deprecated, nor discouraged by any means.  However,
it won''t
> > fit with the restful model.  Consider the code in scaffold_resource,
> > like the code in scaffold, a simple suggestion.
> >
> > Hell, if you find yourself going with your own unique style, take one
> > of those generators and make a personal copy of it that spits it out
> > in the way you like :)
> >
> > --
> > Rick Olsonhttp://weblog.techno-weenie.nethttp://mephistoblog.com
>
> Thanks for the clarification.  Just trying to get a feel for what more
> experienced Rails programmers are doing.
>
> I do have one question about the scaffold_resource generator though.
> I started a new rails project to start experimenting and ran into
> something I thought was a bit strange.  If you use the generator
> before generating a model all seems to go pretty well.  It creates the
> model for you and the scaffold and even adds the map.resources :users
> to the routes.rb file.  But since it all happens at once there are no
> fields in the migration so you get an empty form with just a submit
> button.
>
> So instead I tried creating the model first and filling out my
> migration.  Then after running the scaffold_resources generator it get
> up to the point it tries to create the migration and stops because the
> migration exists already.
>
> What am I doing wrong?
>
> Thanks,
> Robert
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

I have an application that I am adding caching to as several of the 
pages take 8+ seconds to load in production (huge unavoidable queries).  
I have added basic action_caching and the speed improvement was huge.  
The problem is that the view associated with :controller=>homes, 
:action=>''index'' needs to look different for the different
types of
users that I have(admins see all data, normal users see only their data). 

Both types of users access the same pages for the most part but what 
they see on each page is different depending on whether or not they are 
an Administrator.  How can I preserve the two versions of the page in 
the view while still using caching to prevent huge load times?


Thank you,
Matthew Margolis
blog.mattmargolis.net

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

Philip Hallstrom wrote:
>> I have an application that I am adding caching to as several of the
>> pages take 8+ seconds to load in production (huge unavoidable queries).
>> I have added basic action_caching and the speed improvement was huge.
>> The problem is that the view associated with :controller=>homes,
>> :action=>''index'' needs to look different for the
different types of
>> users that I have(admins see all data, normal users see only their
data).
>>
>> Both types of users access the same pages for the most part but what
>> they see on each page is different depending on whether or not they are
>> an Administrator.  How can I preserve the two versions of the page in
>> the view while still using caching to prevent huge load times?
>>     
>
> fragment caching... cache the common parts of the resulting views... then 
> in the controller, check to see if a particular fragment cache already 
> exists before doing the expensive queries...
>
> >
>   
Will this work for a situation where I have one list of data and the 
list either has all entries in a table (if the user is an administrator) 
or just the users entries (if the user is a normal user)?  I would think 
that the fragment would be the same on both pages as the list is in the 
same div.

Thank you,
Matthew Margolis
blog.mattmargolis.net

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

> I have an application that I am adding caching to as several of the
> pages take 8+ seconds to load in production (huge unavoidable queries).
> I have added basic action_caching and the speed improvement was huge.
> The problem is that the view associated with :controller=>homes,
> :action=>''index'' needs to look different for the
different types of
> users that I have(admins see all data, normal users see only their data).
>
> Both types of users access the same pages for the most part but what
> they see on each page is different depending on whether or not they are
> an Administrator.  How can I preserve the two versions of the page in
> the view while still using caching to prevent huge load times?
fragment caching... cache the common parts of the resulting views... then 
in the controller, check to see if a particular fragment cache already 
exists before doing the expensive queries...

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

> Philip Hallstrom wrote:
>>> I have an application that I am adding caching to as several of the
>>> pages take 8+ seconds to load in production (huge unavoidable
queries).
>>> I have added basic action_caching and the speed improvement was
huge.
>>> The problem is that the view associated with :controller=>homes,
>>> :action=>''index'' needs to look different for
the different types of
>>> users that I have(admins see all data, normal users see only their
data).
>>>
>>> Both types of users access the same pages for the most part but
what
>>> they see on each page is different depending on whether or not they
are
>>> an Administrator.  How can I preserve the two versions of the page
in
>>> the view while still using caching to prevent huge load times?
>>>
>>
>> fragment caching... cache the common parts of the resulting views...
then
>> in the controller, check to see if a particular fragment cache already
>> exists before doing the expensive queries...
>>
>>>
>>
> Will this work for a situation where I have one list of data and the
> list either has all entries in a table (if the user is an administrator)
> or just the users entries (if the user is a normal user)?  I would think
> that the fragment would be the same on both pages as the list is in the
> same div.
No, it wouldn''t.

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

Philip Hallstrom wrote:
>> Philip Hallstrom wrote:
>>     
>>>> I have an application that I am adding caching to as several of
the
>>>> pages take 8+ seconds to load in production (huge unavoidable
queries).
>>>> I have added basic action_caching and the speed improvement was
huge.
>>>> The problem is that the view associated with
:controller=>homes,
>>>> :action=>''index'' needs to look different
for the different types of
>>>> users that I have(admins see all data, normal users see only
their data).
>>>>
>>>> Both types of users access the same pages for the most part but
what
>>>> they see on each page is different depending on whether or not
they are
>>>> an Administrator.  How can I preserve the two versions of the
page in
>>>> the view while still using caching to prevent huge load times?
>>>>
>>>>         
>>> fragment caching... cache the common parts of the resulting
views... then
>>> in the controller, check to see if a particular fragment cache
already
>>> exists before doing the expensive queries...
>>>
>>>       
>> Will this work for a situation where I have one list of data and the
>> list either has all entries in a table (if the user is an
administrator)
>> or just the users entries (if the user is a normal user)?  I would
think
>> that the fragment would be the same on both pages as the list is in the
>> same div.
>>     
>
> No, it wouldn''t.
>
> >
>   
Any ideas on how to do this then?  Is there a way to bypass the caching 
if the user is a normal user?  I really only care about the caching for 
administrators as oddly enough this application is used more by admins 
than normal users.

Thank you,
Matthew Margolis
blog.mattmargolis.net

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

Check out my action_cache plugin.   This replaces the Rails action
cache, and then allows you to define the cache keys used for a page,
so you can have different versions of a page cached based on admin or
not.  You could also decide to not cache a page for admins, but cache
for everyone else.

http://agilewebdevelopment.com/plugins/action_cache


On Feb 2, 1:35 pm, Matthew Margolis
<mrmargo...-63mtpxcE9Cs@public.gmane.org> wrote:
> I have an application that I am adding caching to as several of the
> pages take 8+ seconds to load in production (huge unavoidable queries).
> I have added basic action_caching and the speed improvement was huge.
> The problem is that the view associated with :controller=>homes,
> :action=>''index'' needs to look different for the
different types of
> users that I have(admins see all data, normal users see only their data).
>
> Both types of users access the same pages for the most part but what
> they see on each page is different depending on whether or not they are
> an Administrator.  How can I preserve the two versions of the page in
> the view while still using caching to prevent huge load times?
>
> Thank you,
> Matthew Margolis
> blog.mattmargolis.net

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