RESTful Rails and other musings

Rails
1

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 W.
Software Developer
Atlanta, GA

2

On 2/1/07, GoodbyeJava [email protected] 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.

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

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

3

On Feb 1, 2007, at 1:55 PM, Pat M. wrote:

On 2/1/07, GoodbyeJava [email protected] wrote:

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

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

5

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 :slight_smile:

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

6

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

7

On Feb 1, 8:51 pm, “Rick O.” [email protected] wrote:

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 :slight_smile:

–
Rick O.http://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

8

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…

9

Philip H. wrote:

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 M.
blog.mattmargolis.net

10

an Administrator. How can I preserve the two versions of the page in
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.

11

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 M.
blog.mattmargolis.net

12

Philip H. wrote:

they see on each page is different depending on whether or not they are
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 M.
blog.mattmargolis.net

13

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