Is the rails 2.0 scaffold system philosophically ( not technically? ) broken?

Hello,

I've read the (many) re-posts about problems around
scaffolding in
Rails 2.0 and have followed a number of tutorials and fully
understand
"how to scaffold" from a technical perspective,
but  I don't
understand the *mindset* of how to use the new scaffolding. 
It seems
like a productivity- / agility- regress and I'm thinking I
may have
failed to properly grok the new setup.  In the interest of
full
disclosure, I'm coming back to Rails after being in other
toolkits for
about 9 months.

Thanks to the intrepid work of Sean Lynch at (
http://fairleads.blogspot.com/20
07/12/rails-20-and-scaffolding-step-by-step.html
) I found a tutorial that would familiarize me with the raw
"how to
scaffold" material.

I followed his tutorial's step of:

``ruby script/generate scaffold Movie''

Great! From that point I filled in the "columns"
in the migration as I
had done in Rails 1.x.  All I should need to do is run
``rake
db:migrate'' and try adding a new record via the
dynamically-created
view.

When I started the server and navigated
localhost:3000/movies I had
the "create new" button.  When I pushed that
button there were no text
widgets to enter *despite having defined the columns that
corresponded
to said widgets* having been added to the migration ( I have
a lengthy
blog post about how my diagnostics went, for anyone else's
edification
at http://stevengharms.n
et/?p=1063 ).  In short the scaffold that had
been created knew nothing of the columns I had added in the
migration
and, as such, the 'new' view had no widgets.

This struck me as well, wrong.  On Sean's post another user
confirms
the same experience.  I have tried it with sqlite3 / mysql /
postgres
connectors.

Research showed that the scaffold had remained static
relative to the
time that I had done the original aenemic invocation.  Per
``script/
generate scaffold --help'':

./script/generate scaffold post` # no attributes, view will
be anemic

To fix this I had to re-issue the script/generate command
with all the
attributes in "final draft" mode (
``script/generate scaffold movie
title:string text:description one_sheet_url:string'' ) and
then over-
write the old templates ( output stored below, for
legibility, Fig.
1).

The solution implies:
 - You have to get the script/generate command's
"attributes"
arguments *perfect* at time of creation OR
 - You do this overwriting thing that I describe below.

As I recall Rails 1.x's dynamic scaffolding allowed us to
use a
scaffold flexibly strictly based on migrations and rake
db:migrate.
This flexibility allowed us to "sketch" ideas very
rapidly.  Or is it
considered a "Good Thing" that you get a
"perfected" ``generate
scaffold'' command at some point?  If so, what's the
reasoning?  Am I
missing some sort of rake command that "refreshes"
the scaffold
templates?

Based on the comments at Sean's site and some of the
questions in the
comments to DHH's Rails 2. announcement I think there are
others
grappling with this quandry as well.  Can anyone help?

Steven


==Fig. 1==
bash-3.2$ script/generate scaffold movie title:string
text:description
one_sheet_url:string
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/
      exists  app/views/movies
      exists  app/views/layouts/
      exists  test/functional/
      exists  test/unit/
overwrite app/views/movies/index.html.erb? (enter
"h" for help)
[Ynaqdh] y
       force  app/views/movies/index.html.erb
overwrite app/views/movies/show.html.erb? (enter
"h" for help)
[Ynaqdh] y
       force  app/views/movies/show.html.erb
overwrite app/views/movies/new.html.erb? (enter
"h" for help) [Ynaqdh]
y
       force  app/views/movies/new.html.erb
overwrite app/views/movies/edit.html.erb? (enter
"h" for help)
[Ynaqdh] y
       force  app/views/movies/edit.html.erb
   identical  app/views/layouts/movies.html.erb
   identical  public/stylesheets/scaffold.css
  dependency  model
      exists    app/models/
      exists    test/unit/
      exists    test/fixtures/
   identical    app/models/movie.rb
   identical    test/unit/movie_test.rb
        skip    test/fixtures/movies.yml
      exists    db/migrate
Another migration is already named create_movies:
db/migrate/
001_create_movies.rb


--~--~---------~--~----~------------~-------~--~----~
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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Scaffolds != Rails

They're a starting point, and as such just give you
something to start
with.  Scaffolds aren't meant to be your whole application,
so the
code is treated just like code that's written independent of
them: If
your object model changes, then you need to change your
views and
controller logic to match.

--Jeremy

On Jan 2, 2008 12:58 PM, Steven G. Harms
<steven.harmsgmail.com> wrote:
>
> Hello,
>
> I've read the (many) re-posts about problems around
scaffolding in
> Rails 2.0 and have followed a number of tutorials and
fully understand
> "how to scaffold" from a technical
perspective, but  I don't
> understand the *mindset* of how to use the new
scaffolding.  It seems
> like a productivity- / agility- regress and I'm
thinking I may have
> failed to properly grok the new setup.  In the interest
of full
> disclosure, I'm coming back to Rails after being in
other toolkits for
> about 9 months.
>
> Thanks to the intrepid work of Sean Lynch at (
> http://fairleads.blogspot.com/20
07/12/rails-20-and-scaffolding-step-by-step.html
> ) I found a tutorial that would familiarize me with the
raw "how to
> scaffold" material.
>
> I followed his tutorial's step of:
>
> ``ruby script/generate scaffold Movie''
>
> Great! From that point I filled in the
"columns" in the migration as I
> had done in Rails 1.x.  All I should need to do is run
``rake
> db:migrate'' and try adding a new record via the
dynamically-created
> view.
>
> When I started the server and navigated
localhost:3000/movies I had
> the "create new" button.  When I pushed that
button there were no text
> widgets to enter *despite having defined the columns
that corresponded
> to said widgets* having been added to the migration ( I
have a lengthy
> blog post about how my diagnostics went, for anyone
else's edification
> at http://stevengharms.n
et/?p=1063 ).  In short the scaffold that had
> been created knew nothing of the columns I had added in
the migration
> and, as such, the 'new' view had no widgets.
>
> This struck me as well, wrong.  On Sean's post another
user confirms
> the same experience.  I have tried it with sqlite3 /
mysql / postgres
> connectors.
>
> Research showed that the scaffold had remained static
relative to the
> time that I had done the original aenemic invocation. 
Per ``script/
> generate scaffold --help'':
>
> ./script/generate scaffold post` # no attributes, view
will be anemic
>
> To fix this I had to re-issue the script/generate
command with all the
> attributes in "final draft" mode (
``script/generate scaffold movie
> title:string text:description one_sheet_url:string'' )
and then over-
> write the old templates ( output stored below, for
legibility, Fig.
> 1).
>
> The solution implies:
>  - You have to get the script/generate command's
"attributes"
> arguments *perfect* at time of creation OR
>  - You do this overwriting thing that I describe
below.
>
> As I recall Rails 1.x's dynamic scaffolding allowed us
to use a
> scaffold flexibly strictly based on migrations and rake
db:migrate.
> This flexibility allowed us to "sketch" ideas
very rapidly.  Or is it
> considered a "Good Thing" that you get a
"perfected" ``generate
> scaffold'' command at some point?  If so, what's the
reasoning?  Am I
> missing some sort of rake command that
"refreshes" the scaffold
> templates?
>
> Based on the comments at Sean's site and some of the
questions in the
> comments to DHH's Rails 2. announcement I think there
are others
> grappling with this quandry as well.  Can anyone help?
>
> Steven
>
>
> ==Fig. 1==
> bash-3.2$ script/generate scaffold movie title:string
text:description
> one_sheet_url:string
>       exists  app/models/
>       exists  app/controllers/
>       exists  app/helpers/
>       exists  app/views/movies
>       exists  app/views/layouts/
>       exists  test/functional/
>       exists  test/unit/
> overwrite app/views/movies/index.html.erb? (enter
"h" for help)
> [Ynaqdh] y
>        force  app/views/movies/index.html.erb
> overwrite app/views/movies/show.html.erb? (enter
"h" for help)
> [Ynaqdh] y
>        force  app/views/movies/show.html.erb
> overwrite app/views/movies/new.html.erb? (enter
"h" for help) [Ynaqdh]
> y
>        force  app/views/movies/new.html.erb
> overwrite app/views/movies/edit.html.erb? (enter
"h" for help)
> [Ynaqdh] y
>        force  app/views/movies/edit.html.erb
>    identical  app/views/layouts/movies.html.erb
>    identical  public/stylesheets/scaffold.css
>   dependency  model
>       exists    app/models/
>       exists    test/unit/
>       exists    test/fixtures/
>    identical    app/models/movie.rb
>    identical    test/unit/movie_test.rb
>         skip    test/fixtures/movies.yml
>       exists    db/migrate
> Another migration is already named create_movies:
db/migrate/
> 001_create_movies.rb
>
>
> >
>



-- 
http://www.jeremymcana
lly.com/

My books:
Ruby in Practice
http://www.manning.c
om/mcanally/

My free Ruby e-book
http://www.humbl
elittlerubybook.com/

My blogs:
http://www.mrneighborly.
com/
http://www.rubyinpract
ice.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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

So your take could be summarized as:  "The scaffold
system is as good
as it needs to be because you're only going to use it really
briefly
before you start fleshing out proper views".


On Jan 2, 12:05 pm, "Jeremy McAnally"
<jeremymcana...gmail.com>
wrote:
> Scaffolds != Rails
>
> They're a starting point, and as such just give you
something to start
> with.  Scaffolds aren't meant to be your whole
application, so the
> code is treated just like code that's written
independent of them: If
> your object model changes, then you need to change your
views and
> controller logic to match.
>
> --Jeremy
>
> On Jan 2, 2008 12:58 PM, Steven G. Harms
<steven.ha...gmail.com> wrote:
>
>
>
>
>
> > Hello,
>
> > I've read the (many) re-posts about problems
around scaffolding in
> > Rails 2.0 and have followed a number of tutorials
and fully understand
> > "how to scaffold" from a technical
perspective, but  I don't
> > understand the *mindset* of how to use the new
scaffolding.  It seems
> > like a productivity- / agility- regress and I'm
thinking I may have
> > failed to properly grok the new setup.  In the
interest of full
> > disclosure, I'm coming back to Rails after being
in other toolkits for
> > about 9 months.
>
> > Thanks to the intrepid work of Sean Lynch at (
> >http://fairleads.blogspot.com/2007/12/ra
ils-20-and-scaffolding-step-b...
> > ) I found a tutorial that would familiarize me
with the raw "how to
> > scaffold" material.
>
> > I followed his tutorial's step of:
>
> > ``ruby script/generate scaffold Movie''
>
> > Great! From that point I filled in the
"columns" in the migration as I
> > had done in Rails 1.x.  All I should need to do is
run ``rake
> > db:migrate'' and try adding a new record via the
dynamically-created
> > view.
>
> > When I started the server and navigated
localhost:3000/movies I had
> > the "create new" button.  When I pushed
that button there were no text
> > widgets to enter *despite having defined the
columns that corresponded
> > to said widgets* having been added to the
migration ( I have a lengthy
> > blog post about how my diagnostics went, for
anyone else's edification
> > athttp://stevengharms.n
et/?p=1063).  In short the scaffold that had
> > been created knew nothing of the columns I had
added in the migration
> > and, as such, the 'new' view had no widgets.
>
> > This struck me as well, wrong.  On Sean's post
another user confirms
> > the same experience.  I have tried it with sqlite3
/ mysql / postgres
> > connectors.
>
> > Research showed that the scaffold had remained
static relative to the
> > time that I had done the original aenemic
invocation.  Per ``script/
> > generate scaffold --help'':
>
> > ./script/generate scaffold post` # no attributes,
view will be anemic
>
> > To fix this I had to re-issue the script/generate
command with all the
> > attributes in "final draft" mode (
``script/generate scaffold movie
> > title:string text:description
one_sheet_url:string'' ) and then over-
> > write the old templates ( output stored below, for
legibility, Fig.
> > 1).
>
> > The solution implies:
> >  - You have to get the script/generate command's
"attributes"
> > arguments *perfect* at time of creation OR
> >  - You do this overwriting thing that I describe
below.
>
> > As I recall Rails 1.x's dynamic scaffolding
allowed us to use a
> > scaffold flexibly strictly based on migrations and
rake db:migrate.
> > This flexibility allowed us to "sketch"
ideas very rapidly.  Or is it
> > considered a "Good Thing" that you get a
"perfected" ``generate
> > scaffold'' command at some point?  If so, what's
the reasoning?  Am I
> > missing some sort of rake command that
"refreshes" the scaffold
> > templates?
>
> > Based on the comments at Sean's site and some of
the questions in the
> > comments to DHH's Rails 2. announcement I think
there are others
> > grappling with this quandry as well.  Can anyone
help?
>
> > Steven
>
> > ==Fig. 1==
> > bash-3.2$ script/generate scaffold movie
title:string text:description
> > one_sheet_url:string
> >       exists  app/models/
> >       exists  app/controllers/
> >       exists  app/helpers/
> >       exists  app/views/movies
> >       exists  app/views/layouts/
> >       exists  test/functional/
> >       exists  test/unit/
> > overwrite app/views/movies/index.html.erb? (enter
"h" for help)
> > [Ynaqdh] y
> >        force  app/views/movies/index.html.erb
> > overwrite app/views/movies/show.html.erb? (enter
"h" for help)
> > [Ynaqdh] y
> >        force  app/views/movies/show.html.erb
> > overwrite app/views/movies/new.html.erb? (enter
"h" for help) [Ynaqdh]
> > y
> >        force  app/views/movies/new.html.erb
> > overwrite app/views/movies/edit.html.erb? (enter
"h" for help)
> > [Ynaqdh] y
> >        force  app/views/movies/edit.html.erb
> >    identical  app/views/layouts/movies.html.erb
> >    identical  public/stylesheets/scaffold.css
> >   dependency  model
> >       exists    app/models/
> >       exists    test/unit/
> >       exists    test/fixtures/
> >    identical    app/models/movie.rb
> >    identical    test/unit/movie_test.rb
> >         skip    test/fixtures/movies.yml
> >       exists    db/migrate
> > Another migration is already named create_movies:
db/migrate/
> > 001_create_movies.rb
>
> --http://www.jeremymcana
lly.com/
>
> My books:
> Ruby in Practicehttp://www.manning.c
om/mcanally/
>
> My free Ruby e-bookhttp://www.humbl
elittlerubybook.com/
>
> My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.
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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jeremy McAnally wrote:
> Scaffolds != Rails
> 

No, but the simplicity of the Rails 1.x scaffold is what
'sold' Rails to 
a lot of people (e.g. via the famous DHH Blog app video on
the Rails 
site). Personally, I think it would have been nice to have
kept the 
'backwards compatibility' intact so that newcomers would
have ready 
access to all the Rails 1.0 tutorials available rather than
trying to 
follow those tutorials and immediately running up against
the buffers, 
so to speak... 

best wishes
Huw

http://www.sapphiresteel
.com
Ruby In Steel for Visual Studio
-- 
Posted via http://www.ruby-forum.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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I believe you can still install it from a plugin if you're
really
interested in it.

I think dynamic scaffolding was a crutch that kept people
from really
getting Rails from the start (i.e., you didn't have to build
views so
they were missing out on that).  I think making them
generate the code
gets them elbow deep in the sort of stuff they'll be writing
quicker.

--Jeremy

On Jan 2, 2008 1:38 PM, Huw Collingbourne
<rails-mailing-listandreas-s.net> wrote:
>
> Jeremy McAnally wrote:
> > Scaffolds != Rails
> >
>
> No, but the simplicity of the Rails 1.x scaffold is
what 'sold' Rails to
> a lot of people (e.g. via the famous DHH Blog app video
on the Rails
> site). Personally, I think it would have been nice to
have kept the
> 'backwards compatibility' intact so that newcomers
would have ready
> access to all the Rails 1.0 tutorials available rather
than trying to
> follow those tutorials and immediately running up
against the buffers,
> so to speak... 
>
> best wishes
> Huw
>
> http://www.sapphiresteel
.com
> Ruby In Steel for Visual Studio
> --
> Posted via http://www.ruby-forum.com
/.
>
>
> >
>



-- 
http://www.jeremymcana
lly.com/

My books:
Ruby in Practice
http://www.manning.c
om/mcanally/

My free Ruby e-book
http://www.humbl
elittlerubybook.com/

My blogs:
http://www.mrneighborly.
com/
http://www.rubyinpract
ice.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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Breaking backward compatibility is a luxury that only
open-source
developers can afford.   It costs nothing to lose customers
if they
aren't paying.  If you need to maintain your customer base
(like, for
example, Microsoft does) then you do anything to avoid
breaking
backward compatibility.

See for example: http://blogs.msdn.com/oldnewthing/archive/2006/1
1/06/999999.aspx

I personally was quite shocked to see that Rails 2 knowingly
broke
things.  Extracting to a plugin I can deal with.  Outright
removal is
shocking.

fredistic

--~--~---------~--~----~------------~-------~--~----~
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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Even though this is a bit off-topic, Rails didn't
arbitrarily break
things.  Developers who use Rails use the code: it's
exposed, we
manipulate it, and it's what we use in our applications. 
Therefore,
it's in the best interest of everyone involved if Rails cuts
out the
cruft while pushing towards better solutions.  If someone
wants to
keep using old feature, they're welcome to keep using the
version of
Rails they're using.

I would hate to end up with a 35MB framework that could
easily be 2MB
or less but has kept so much stuff around in the interest of
backwards
compatibility.

--Jeremy

On Jan 2, 2008 3:20 PM, fredistic <fredisticgmail.com> wrote:
>
> Breaking backward compatibility is a luxury that only
open-source
> developers can afford.   It costs nothing to lose
customers if they
> aren't paying.  If you need to maintain your customer
base (like, for
> example, Microsoft does) then you do anything to avoid
breaking
> backward compatibility.
>
> See for example: http://blogs.msdn.com/oldnewthing/archive/2006/1
1/06/999999.aspx
>
> I personally was quite shocked to see that Rails 2
knowingly broke
> things.  Extracting to a plugin I can deal with. 
Outright removal is
> shocking.
>
> fredistic
>
>
> >
>



-- 
http://www.jeremymcana
lly.com/

My books:
Ruby in Practice
http://www.manning.c
om/mcanally/

My free Ruby e-book
http://www.humbl
elittlerubybook.com/

My blogs:
http://www.mrneighborly.
com/
http://www.rubyinpract
ice.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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Um, this looks interesting:
http://wiki.rubyonrails.org/rails/pages/Sca
ffolding+Extensions+Plugin

f

--~--~---------~--~----~------------~-------~--~----~
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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 2, 2008, at 9:20 PM, fredistic wrote:

> Breaking backward compatibility is a luxury that only
open-source
> developers can afford.   It costs nothing to lose
customers if they
> aren't paying.  If you need to maintain your customer
base (like, for
> example, Microsoft does) then you do anything to avoid
breaking
> backward compatibility.

Fortunately, open-source projects are not run by money. They
respect  
their users, and that's why there's a cycle of
deprecation/removal  
going on. Warnings about deprecated stuff all over the
place,  
documentation, etc.

A major release is allowed to break things, that's what the
2.0  
signals. You can put the version of Rails your application
is known to  
run OK under vendor/rails, or revise and upgrade.

To polish and continue improving something you need to add,
but you  
need to cut as well. A major release allows cutting.

-- fxn


--~--~---------~--~----~------------~-------~--~----~
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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 2, 2008 4:11 PM, Xavier Noria <fxnhashref.com> wrote:
>
> On Jan 2, 2008, at 9:20 PM, fredistic wrote:
>
> > Breaking backward compatibility is a luxury that
only open-source
> > developers can afford.   It costs nothing to lose
customers if they
> > aren't paying.  If you need to maintain your
customer base (like, for
> > example, Microsoft does) then you do anything to
avoid breaking
> > backward compatibility.
>
> Fortunately, open-source projects are not run by money.
They respect
> their users, and that's why there's a cycle of
deprecation/removal
> going on. Warnings about deprecated stuff all over the
place,
> documentation, etc.
>
> A major release is allowed to break things, that's what
the 2.0
> signals. You can put the version of Rails your
application is known to
> run OK under vendor/rails, or revise and upgrade.
>
> To polish and continue improving something you need to
add, but you
> need to cut as well. A major release allows cutting.

And there's no one holding a gun to anyone's head forcing
them to use
the new versions.  You can wait until you are ready, the old
versions
are still there.

Applications using frameworks like Rails are tied to the
implementation of the version of the framework they use. 
This is okay
as long as you can control if and when you move to a new
version.
Some years ago, there was a lot of interest in the idea of
making
framework-based operating systems.   Here's a war story from
those
days: http://talklikeaduck.denhaven2.c
om/articles/2007/06/15/a-meeting-with-gill-bates

-- 
Rick DeNatale

My blog on Ruby
http://talklikead
uck.denhaven2.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-talkgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---