Rails - Jan 2008 - 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/2007/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.net/?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-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
-~----------~----~----~----~------~----~------~--~---

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.harms-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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/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.net/?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.jeremymcanally.com/

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

My free Ruby e-book
http://www.humblelittlerubybook.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-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
-~----------~----~----~----~------~----~------~--~---

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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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/rails-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.net/?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.jeremymcanally.com/
>
> My books:
> Ruby in Practicehttp://www.manning.com/mcanally/
>
> My free Ruby e-bookhttp://www.humblelittlerubybook.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-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
-~----------~----~----~----~------~----~------~--~---

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-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 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-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
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.jeremymcanally.com/

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

My free Ruby e-book
http://www.humblelittlerubybook.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-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
-~----------~----~----~----~------~----~------~--~---

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

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
<fredistic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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/11/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.jeremymcanally.com/

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

My free Ruby e-book
http://www.humblelittlerubybook.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-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
-~----------~----~----~----~------~----~------~--~---

Um, this looks interesting:
http://wiki.rubyonrails.org/rails/pages/Scaffolding+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-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 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-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 Jan 2, 2008 4:11 PM, Xavier Noria
<fxn-xlncskNFVEJBDgjK7y7TUQ@public.gmane.org>
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.com/articles/2007/06/15/a-meeting-with-gill-bates

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.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-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 Jan 2, 2008 12:20 PM, fredistic
<fredistic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Breaking backward compatibility is a luxury that only open-source
> developers can afford.
Backwards compatibility is frequently very expensive.  Microsoft in
particular expends vast amounts of resources on backwards
compatibility, and quite a bit of that effort is almost entirely
useless to the vast majority of their customers.

Would you rather have those engineers working on new/improved
functionality, or on bug-for-bug compatibility that''s only interesting
to a tiny minority of users?

Think of backwards compatibility as a tax that older users impose on
newer users.  That may be worth paying; newer users may themselves
want backwards compatibility in the future.

But the community may also decide that tax isn''t worth paying.  Older
users may be required to spend resources to use newer versions of the
system in question.  That''s OK; they''re getting the benefits
of
development resources applied to the newer versions too.
> If you need to maintain your customer base (like, for
> example, Microsoft does) then you do anything to avoid breaking
> backward compatibility.
Not at all.  Older users just have to spend some resources making sure
they''re good on the newer system.  It''s one of those
engineering/business decisions that people make every day.

-- 
James Moore | james-7AXNjMB9LsNl57MIdRCFDg@public.gmane.org
Ruby and Ruby on Rails consulting
blog.restphone.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
-~----------~----~----~----~------~----~------~--~---

Philosophical arguments aside, if they were going to take it out, they 
should have, well, just taken the whole thing out. I should just get an 
error when I try to create a scaffold if it isn''t going to get made 
properly.

All this about backward compatibility is all fine and good; but at the 
very least i should get a deprec message instead of having to hunt 
through the erb files in the vestigial scaffold remnants that don''t 
work, re-rake, see that nothing changed, question my own sanity, then do 
a Google search and come here. It doesn''t make sense.
-- 
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-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
-~----------~----~----~----~------~----~------~--~---

> All this about backward compatibility is all fine and good; but at the
> very least i should get a deprec message instead of having to hunt
> through the erb files in the vestigial scaffold remnants that
don''t
> work, re-rake, see that nothing changed, question my own sanity, then do
> a Google search and come here. It doesn''t make sense.
I suggest to delegate the scaffolding to a plugin which specializes
with this task, for instance http://activescaffold.com/.

(yeah that doesn''t answer the philosophical question for sure!)

best wishes !

Thibaut Barrère / LoGeek
--
http://blog.logeek.fr - about writing software
http://evolvingworker.com - tools for a better day
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

So,
Many older tutorials (and books) suggested a method of working models
and relations like:
generate model, scaffold, migrate, check, migrate, check... (e.g. the
original blog-video and the depot tutorial)

That is all deprecated and replaced by... what?
How will the rewrites look?
What is the new preferred way of working?

I was quite comfortable with this way of working myself and I haven''t
really found something to fill the void yet.
I don''t want to sound critical. I would just love to get the scoop on
what has made scaffolding more or less obsolete in the eyes of the
core team.

My current guess is that I should start using the console more when
being interactive with models.

cheers.
Martin Westn

On Jan 5, 12:05 pm, "Thibaut Barrère"
<thibaut.barr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > All this about backward compatibility is all fine and good; but at the
> > very least i should get a deprec message instead of having to hunt
> > through the erb files in the vestigialscaffoldremnants that
don''t
> > work, re-rake, see that nothing changed, question my own sanity, then
do
> > a Google search and come here. It doesn''t make sense.
>
> I suggest to delegate the scaffolding to a plugin which specializes
> with this task, for instancehttp://activescaffold.com/.
>
> (yeah that doesn''t answer the philosophical question for sure!)
>
> best wishes !
>
> Thibaut Barrère / LoGeek
> --http://blog.logeek.fr- about writing softwarehttp://evolvingworker.com-
tools for a better day
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Dynamic scaffolds give you squat. You got one line of code doing some 
magical things so your browser renders some magical other things -
don''t
tell me you can learn the framework by staring at that line long enough 
until it conveys meaning. It won''t.

There''s a place for it of course: marketing material. Shiny "oh
look
this is so great" screencasts, which imply that your next big Web2.0 
Buzzword-Compliant Social Networking app is just ten minutes away.

What you can do is script/generate scaffold Foo bar:text - that''ll give
you stuff to look at, and if you don''t like what you see you actually 
have the chance to change stuff. Also, it does what the name implies 
("scaffold", remember?), which is A Good Thing.

In other news, the "preferred way of working" is still, after all
those
years, to actually writing code while knowing wtf is going on.

Oh, and another reason: everytime someone writes scaffold into their 
text editor or irc client, god kills a kitten. true story.


Martin wrote:
> So,
> Many older tutorials (and books) suggested a method of working models
> and relations like:
> generate model, scaffold, migrate, check, migrate, check... (e.g. the
> original blog-video and the depot tutorial)
> 
> That is all deprecated and replaced by... what?
> How will the rewrites look?
> What is the new preferred way of working?
> 
> I was quite comfortable with this way of working myself and I
haven''t
> really found something to fill the void yet.
> I don''t want to sound critical. I would just love to get the scoop
on
> what has made scaffolding more or less obsolete in the eyes of the
> core team.
> 
> My current guess is that I should start using the console more when
> being interactive with models.
> 
> cheers.
> Martin Westn
> 
> On Jan 5, 12:05�pm, "Thibaut Barr�re"
<thibaut.barr...@gmail.com>
-- 
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-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
-~----------~----~----~----~------~----~------~--~---

Sooooo....I''m guessing there''s no more code generation huh?

These sorts of decisions usually make tons of sense to core developers
on a framework. However, to the masses, it may be a quite different.

Here is a newbie''s perspective:
I''ve been into web frameworks for about a year now. And the
"magic" of
code generation is what drew me in. CakePHP has a "bake" feature,
which  doesn''t do a 1/4 of the stuff I''ve seen RoR do in the
12 hours
I''ve been messing with it. I stayed a way from RoR this long for the
simple fact that I didn''t see the need tl learn Ruby, due to
it''s
"interesting" syntax.

Recently I saw a screen cast of the RadRails plugin and I was sold on
RoR. Along with the fact that it''s more established and has a larger
following. From all the tutorials I''ve been reading the code
generation was light years ahead of CakePHP. So I''m thinking,
I''ll
install this guy, install that cool IDE, and get going with the Agive
Web Dev. Book and a few tutorials. I figured the quickest way to get
into RoR is to port some of my CakePHP apps: import that databases
(schema conventions seem to mimic RoR), slap on some scaffolding to
generate my MVC''s, then peer into the code. There are sooooo many
plugins there, I couldn''t wait to get started on more complicated
things like AJAX, Auth, etc.

12 hours later, I''m still trying to scaffold that stupid cookbook2
with two tables in it. I thought I was doing something wrong. I
figured, it already got the schema of the database, how hard could it
be to build the stupid models, controllers and views. To my great
dismay, I''ve come to learn they have been removed? Wow.

Sorry for the rant, but I don''t really understand. What''s the
point of
all the visual database design tools, if at the end of the day, I
still gotta write everything in the migration syntax? I see where all
the migration stuff can come in handy for "revisions", but when
starting off, I don''t get it. Yes, scaffolding will give you a lot
more stuff than you need. But, IMO, it''s much easier to sit on the
delete key for a while, than it is to go write code that you don''t
understand.

Can someone please tell me that I''m mistaken. And that there HAS to be
a way around this? How do I get tons of SQL into an "initial"
migration, so that I can generate MVC''s from there?

ThanX in advance.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Scaffolding is great for newbies trying to learn the language, but for us
more experienced folk, it''s just more added cruft. We''re so
used to writing
our own controllers the way we want to write them and different people have
different ways to writing their controllers. Controllers are not that hard
to write, really! I find the views much harder. Controllers are usually 7
actions to start off with and generally go something like this:

class LightController < ApplicationController

def index
  @lights = Light.find(:all)
end

def show
  @light = Light.find(params[:id])
  rescue ActiveRecord::RecordNotFound
    flash[:notice] = "The light you were looking for could not be
found."
    redirect_to lights_path
end

def new
  @light = Light.new
end

def create
  @light = Light.new(params[:light])
  if @light.save
    flash[:notice] = "A new light has been created."
    redirect_to light_path
  else
   flash[:notice] = "A new light could not be created.
   render :action => "new"
end

end

def edit
  @light = Light.find(params[:id])
  rescue ActiveRecord::RecordNotFound
    flash[:notice] = "The light you were looking for could not be
found."
    redirect_to lights_path
end

def update
  @light = Light.find(params[:id])
  if @light.save
    flash[:notice] = "This light has been updated."
    redirect_to light_path
  else
    flash[:notice] = "This light could not be updated."
    render :action => "edit"
  end
  rescue ActiveRecord::RecordNotFound
     flash[:notice] = "The light you were looking for could not be
found."
     redirect_to lights_path
end

def destroy
  @light = Light.find(params[:id])
  @light.destroy
  flash[:notice] = "The selected light has been destroyed."
  rescue ActiveRecord::RecordNotFound
     flash[:notice] = "The light you were looking for could not be
found."
  ensure
     redirect_to lights_path
end

I''ve made a note to myself to make this into a generator. If you want
to use
it I''ll be able to upload it somewhere tomorrow.

I doubt that you''ve spent 12 hours trying to scaffold cookbook 2.
You''ve
probably spent 15 minutes on it and gone "this is too hard!" and gave
up.
Persist. If you have any issues, post them here. We can help.

--~--~---------~--~----~------------~-------~--~----~
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 guess the Rails core team has become a little out of touch with the
newbie developer.  But, frankly, that''s a necessary step for the
maturation of a project like this.  3 years ago, Rails needed all the
mindshare it could get, and the infamous screencast was a powerful
hook to draw people in.

These days things are different.  The core team is trying to Rails as
powerful as possible for it''s large userbase without bloat.  So far
the vision has been maintained extremely well.  Maybe the decisions
with scaffolding don''t sit well with everyone.  The problem is when
debate happens in the core community, scaffolding is the last thing on
everyone''s list to worry about.

I really sympathize with the effect of undocumented changes and out of
date tutorials--I''ve been burned plenty.  But scaffolding really is
such an insignificant part of Rails that its flaws should have no
bearing on your decision of whether or not to use Rails.  Rails isn''t
a visual toolkit, it''s a serious development framework.  You just have
to make it over two humps in the learning curve: the Rails API hump
and then later the Dynamic Ruby hump and you''ll be golden.

On Feb 23, 4:26 am, Baz L
<bazil...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Sooooo....I''m guessing there''s no more code generation
huh?
>
> These sorts of decisions usually make tons of sense to core developers
> on a framework. However, to the masses, it may be a quite different.
>
> Here is a newbie''s perspective:
> I''ve been into web frameworks for about a year now. And the
"magic" of
> code generation is what drew me in. CakePHP has a "bake" feature,
> which  doesn''t do a 1/4 of the stuff I''ve seen RoR do in
the 12 hours
> I''ve been messing with it. I stayed a way from RoR this long for
the
> simple fact that I didn''t see the need tl learn Ruby, due to
it''s
> "interesting" syntax.
>
> Recently I saw a screen cast of the RadRails plugin and I was sold on
> RoR. Along with the fact that it''s more established and has a
larger
> following. From all the tutorials I''ve been reading the code
> generation was light years ahead of CakePHP. So I''m thinking,
I''ll
> install this guy, install that cool IDE, and get going with the Agive
> Web Dev. Book and a few tutorials. I figured the quickest way to get
> into RoR is to port some of my CakePHP apps: import that databases
> (schema conventions seem to mimic RoR), slap on some scaffolding to
> generate my MVC''s, then peer into the code. There are sooooo many
> plugins there, I couldn''t wait to get started on more complicated
> things like AJAX, Auth, etc.
>
> 12 hours later, I''m still trying to scaffold that stupid cookbook2
> with two tables in it. I thought I was doing something wrong. I
> figured, it already got the schema of the database, how hard could it
> be to build the stupid models, controllers and views. To my great
> dismay, I''ve come to learn they have been removed? Wow.
>
> Sorry for the rant, but I don''t really understand. What''s
the point of
> all the visual database design tools, if at the end of the day, I
> still gotta write everything in the migration syntax? I see where all
> the migration stuff can come in handy for "revisions", but when
> starting off, I don''t get it. Yes, scaffolding will give you a lot
> more stuff than you need. But, IMO, it''s much easier to sit on the
> delete key for a while, than it is to go write code that you don''t
> understand.
>
> Can someone please tell me that I''m mistaken. And that there HAS
to be
> a way around this? How do I get tons of SQL into an "initial"
> migration, so that I can generate MVC''s from there?
>
> ThanX in advance.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi Everyone,

I''ve read each post in this thread & I cannot believe the
misunderstanding of ''scaffold'' in rails 2.0.2

As Johannes puts it so well...
>>>>>> Quote
Dynamic scaffolds give you squat. You got one line of code doing some
magical things so your browser renders some magical other things -
don''t
tell me you can learn the framework by staring at that line long
enough
until it conveys meaning. It won''t.
<<<<<<<< End Quote

Can I suggest those who are complaining about this change follow
"Akita''s" tutorial on rails 2, which should enlighten you to
what the
change is all about in a real context !
http://www.akitaonrails.com/2008/2/1/rolling-with-rails-2-0-pdf-version

HTH - Dave Porter


On Feb 23, 11:45 pm, dasil003
<gabrie...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I guess the Rails core team has become a little out of touch with the
> newbie developer.  But, frankly, that''s a necessary step for the
> maturation of a project like this.  3 years ago, Rails needed all the
> mindshare it could get, and the infamous screencast was a powerful
> hook to draw people in.
>
> These days things are different.  The core team is trying to Rails as
> powerful as possible for it''s large userbase without bloat.  So
far
> the vision has been maintained extremely well.  Maybe the decisions
> with scaffolding don''t sit well with everyone.  The problem is
when
> debate happens in the core community, scaffolding is the last thing on
> everyone''s list to worry about.
>
> I really sympathize with the effect of undocumented changes and out of
> date tutorials--I''ve been burned plenty.  But scaffolding really
is
> such an insignificant part of Rails that its flaws should have no
> bearing on your decision of whether or not to use Rails.  Rails
isn''t
> a visual toolkit, it''s a serious development framework.  You just
have
> to make it over two humps in the learning curve: the Rails API hump
> and then later the Dynamic Ruby hump and you''ll be golden.
>
> On Feb 23, 4:26 am, Baz L
<bazil...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Sooooo....I''m guessing there''s no more code
generation huh?
>
> > These sorts of decisions usually make tons of sense to core developers
> > on a framework. However, to the masses, it may be a quite different.
>
> > Here is a newbie''s perspective:
> > I''ve been into web frameworks for about a year now. And the
"magic" of
> > code generation is what drew me in. CakePHP has a "bake"
feature,
> > which  doesn''t do a 1/4 of the stuff I''ve seen RoR
do in the 12 hours
> > I''ve been messing with it. I stayed a way from RoR this long
for the
> > simple fact that I didn''t see the need tl learn Ruby, due to
it''s
> > "interesting" syntax.
>
> > Recently I saw a screen cast of the RadRails plugin and I was sold on
> > RoR. Along with the fact that it''s more established and has a
larger
> > following. From all the tutorials I''ve been reading the code
> > generation was light years ahead of CakePHP. So I''m thinking,
I''ll
> > install this guy, install that cool IDE, and get going with the Agive
> > Web Dev. Book and a few tutorials. I figured the quickest way to get
> > into RoR is to port some of my CakePHP apps: import that databases
> > (schema conventions seem to mimic RoR), slap on some scaffolding to
> > generate my MVC''s, then peer into the code. There are sooooo
many
> > plugins there, I couldn''t wait to get started on more
complicated
> > things like AJAX, Auth, etc.
>
> > 12 hours later, I''m still trying to scaffold that stupid
cookbook2
> > with two tables in it. I thought I was doing something wrong. I
> > figured, it already got the schema of the database, how hard could it
> > be to build the stupid models, controllers and views. To my great
> > dismay, I''ve come to learn they have been removed? Wow.
>
> > Sorry for the rant, but I don''t really understand.
What''s the point of
> > all the visual database design tools, if at the end of the day, I
> > still gotta write everything in the migration syntax? I see where all
> > the migration stuff can come in handy for "revisions", but
when
> > starting off, I don''t get it. Yes, scaffolding will give you
a lot
> > more stuff than you need. But, IMO, it''s much easier to sit
on the
> > delete key for a while, than it is to go write code that you
don''t
> > understand.
>
> > Can someone please tell me that I''m mistaken. And that there
HAS to be
> > a way around this? How do I get tons of SQL into an
"initial"
> > migration, so that I can generate MVC''s from there?
>
> > ThanX in advance.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Maybe the use of the term scaffolding is wrong. I meant the code generation
from the migration.

Everyone here is always going to say that it''s not hard to write your
own
controllers. I''m not saying it''s hard. I''m saying, as
a newbie developer in
the framework, it''s a great helping tool. For me, web development is
about
getting stuff done.

But seriously, how does one "import" and already existing database
design
into a Rails Project? I''m talking about 100+ tables, with (on average)
20+
fields.

Does one need to specify script/generate model (and all 20 fields)?

On Sat, Feb 23, 2008 at 9:29 AM, Davo
<Dave.SouthPerth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> Hi Everyone,
>
> I''ve read each post in this thread & I cannot believe the
> misunderstanding of ''scaffold'' in rails 2.0.2
>
> As Johannes puts it so well...
>
> >>>>>> Quote
> Dynamic scaffolds give you squat. You got one line of code doing some
> magical things so your browser renders some magical other things -
> don''t
> tell me you can learn the framework by staring at that line long
> enough
> until it conveys meaning. It won''t.
> <<<<<<<< End Quote
>
> Can I suggest those who are complaining about this change follow
> "Akita''s" tutorial on rails 2, which should enlighten
you to what the
> change is all about in a real context !
> http://www.akitaonrails.com/2008/2/1/rolling-with-rails-2-0-pdf-version
>
> HTH - Dave Porter
>
>
> On Feb 23, 11:45 pm, dasil003
<gabrie...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I guess the Rails core team has become a little out of touch with the
> > newbie developer.  But, frankly, that''s a necessary step for
the
> > maturation of a project like this.  3 years ago, Rails needed all the
> > mindshare it could get, and the infamous screencast was a powerful
> > hook to draw people in.
> >
> > These days things are different.  The core team is trying to Rails as
> > powerful as possible for it''s large userbase without bloat. 
So far
> > the vision has been maintained extremely well.  Maybe the decisions
> > with scaffolding don''t sit well with everyone.  The problem
is when
> > debate happens in the core community, scaffolding is the last thing on
> > everyone''s list to worry about.
> >
> > I really sympathize with the effect of undocumented changes and out of
> > date tutorials--I''ve been burned plenty.  But scaffolding
really is
> > such an insignificant part of Rails that its flaws should have no
> > bearing on your decision of whether or not to use Rails.  Rails
isn''t
> > a visual toolkit, it''s a serious development framework.  You
just have
> > to make it over two humps in the learning curve: the Rails API hump
> > and then later the Dynamic Ruby hump and you''ll be golden.
> >
> > On Feb 23, 4:26 am, Baz L
<bazil...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > Sooooo....I''m guessing there''s no more code
generation huh?
> >
> > > These sorts of decisions usually make tons of sense to core
developers
> > > on a framework. However, to the masses, it may be a quite
different.
> >
> > > Here is a newbie''s perspective:
> > > I''ve been into web frameworks for about a year now. And
the "magic" of
> > > code generation is what drew me in. CakePHP has a
"bake" feature,
> > > which  doesn''t do a 1/4 of the stuff I''ve seen
RoR do in the 12 hours
> > > I''ve been messing with it. I stayed a way from RoR this
long for the
> > > simple fact that I didn''t see the need tl learn Ruby,
due to it''s
> > > "interesting" syntax.
> >
> > > Recently I saw a screen cast of the RadRails plugin and I was
sold on
> > > RoR. Along with the fact that it''s more established and
has a larger
> > > following. From all the tutorials I''ve been reading the
code
> > > generation was light years ahead of CakePHP. So I''m
thinking, I''ll
> > > install this guy, install that cool IDE, and get going with the
Agive
> > > Web Dev. Book and a few tutorials. I figured the quickest way to
get
> > > into RoR is to port some of my CakePHP apps: import that
databases
> > > (schema conventions seem to mimic RoR), slap on some scaffolding
to
> > > generate my MVC''s, then peer into the code. There are
sooooo many
> > > plugins there, I couldn''t wait to get started on more
complicated
> > > things like AJAX, Auth, etc.
> >
> > > 12 hours later, I''m still trying to scaffold that stupid
cookbook2
> > > with two tables in it. I thought I was doing something wrong. I
> > > figured, it already got the schema of the database, how hard
could it
> > > be to build the stupid models, controllers and views. To my great
> > > dismay, I''ve come to learn they have been removed? Wow.
> >
> > > Sorry for the rant, but I don''t really understand.
What''s the point of
> > > all the visual database design tools, if at the end of the day, I
> > > still gotta write everything in the migration syntax? I see where
all
> > > the migration stuff can come in handy for "revisions",
but when
> > > starting off, I don''t get it. Yes, scaffolding will give
you a lot
> > > more stuff than you need. But, IMO, it''s much easier to
sit on the
> > > delete key for a while, than it is to go write code that you
don''t
> > > understand.
> >
> > > Can someone please tell me that I''m mistaken. And that
there HAS to be
> > > a way around this? How do I get tons of SQL into an
"initial"
> > > migration, so that I can generate MVC''s from there?
> >
> > > ThanX in advance.
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 23, 2:45 pm, dasil003
<gabrie...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I guess the Rails core team has become a little out of touch with the
> newbie developer.  But, frankly, that''s a necessary step for the
> maturation of a project like this.  3 years ago, Rails needed all the
> mindshare it could get, and the infamous screencast was a powerful
> hook to draw people in.
>
This is the first time I have been unpleasantly surprised by a comment
on this forum.  I wonder if this reflects the views of the core team.

Working on creating 2 large apps based on rails 1, I am in the process
of moving them to Rails 2.  But I sense a significant distance between
the core Rails Movers and "the Rest of us".  So much of the
documentation (which was in any case not ideal) has now been confused,
and left behind.  As an existing Rails developer, I can just about
cope with the transition of how to convert to plugins for things like
pagination, auto_complete etc.  (But for a good summary of the changes
I was forced to buy the peepcode pdf)  I dont mind paying , but I
would if I was just trying rails out for the first time .   So many of
the tutorials are now going to just not work for Rails 2 and are going
to point in the wrong direction, particularly as regards REST (and
consequently the scaffold) and routing which is getting a fairly high
profile.  Even the Agile Rails book is no longer being quoted as the
Primary resource.   I suspect if I were coming as a noob, then this
amount of confusion, on top of the lack of a single documentation
resource, would cause me to give up in disgust.

Now I do not want to be a complainer.  I do not have any problems with
the Rails 2 direction, and getting to grips with REST routing and the
various concepts is really good for me.  But if there is no leg up for
those entering the fray for the first time,and it is felt that
maturing the product necessitates losing touch with the noob,  there
is a danger that Rails could become an old boy''s club.  (Purely my own
opinion, but that would be a real shame - I have been a strong
advocate of Rails.)

Being a transition from 1 to 2, means this is Rails first experience
in version transition.   The rails team has got so much right that it
would be a shame to dismiss the significance of the version
transition.   I think there is merit in the view that need for total
backward compatibility can be dispensed with.  But if that is done
without clear documentation for the transition and its implications
(prominantly on the Rails home site - cos  that is the logical first
place to look), then it is just going to leave confusion to eventually
do its worst.

comments made with good intentions - reflecting my own feelings along
the way.
Tonypm


--~--~---------~--~----~------------~-------~--~----~
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 24, 2008, at 4:33 AM, tonypm wrote:
> So many of
> the tutorials are now going to just not work for Rails 2 and are going
> to point in the wrong direction, particularly as regards REST (and
> consequently the scaffold) and routing which is getting a fairly high
> profile.
@tonypm--

These changes cannot have come as a surprise to anyone who was  
tracking Rails. As with anything that has a good deal of Internet  
buzz, some of that buzz will not be updated to reflect the news.  
Still, the benefits of extracting certain functionality from Rails  
core was articulated very early. It is not the fault of the Rails core  
team that so much of the existing information you can turn up using  
Google focuses on earlier versions of Rails.

Several blogs have meticulously tracked the changes as Rails core has  
merged them into edge:

http://ryandaigle.com/
http://blog.hasmanythrough.com/

Are two good places to look. I single these two out, not because they  
are the only places to look, but rather because they are the first  
that come to mind. I even wrote a post on upgrading to Rails 2.0 that  
addressed dynamic scaffolding:

http://calicowebdev.com/blog/show/17

The regrettable thing about this is that dynamic scaffolding was such  
an eye-popping feature that people got used to highlighting it as an  
example of the true productivity one might achieve using Rails. In  
practice, many Rails 1.x (if not most) developers wound up creating  
their own actions and views to replace the dynamic scaffolds, yet the  
code remained in the Rails codebase. That became, essentially, dead  
code in the production codebase. Yet is cost time for the core team to  
maintain. There are other dynamic scaffold solutions available, and  
while not covered exhaustively in the "how-to''s" that are so
pervasive
on the Web, they may do an even better job that Rails'' original one.

Pagination is another place that may disappoint. But Rails pagination  
was not considered a great solution. Many, many posts to this list  
complained about poor performance. Several replacements have emerged  
that are superior, the most popular being will_paginate (http://errtheblog.com 
). Another one is paginating_find
(http://cardboardrocket.com/pages/paginating_find
), which I''ve used to good effect in some applications.

I encourage you to consider the Rails core team a limited resource and  
ask yourself whether you would prefer they spend their time keeping up  
with legacy features (even though there are better alternatives for  
them) or pushing forward.

My $.02

--~--~---------~--~----~------------~-------~--~----~
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''ve spoken with a lot of people who are in the process of learning
Rails, and I believe the core team made a big mistake in removing the
basic scaffold and renaming scaffold_resource to scaffold.

I understand the thinking that led to this, and I don''t object to the
goal of pushing RESTful design. For experienced developers the change
in the scaffold command is not a problem. But it unnecessarily broke
nearly every existing tutorial. Using the "new" scaffold command in a
tutorial that was written for the "old" scaffold command gives no
errors, it just leads to code that doesn''t work as intended. This has
left a lot of people confused, frustrated, and less likely to continue
with Rails. And it was completely unnecessary.

Removing features is one thing. I don''t regret the loss of dynamic
scaffolding. And I don''t want a bloated framework either. But taking a
feature that is almost universally used in introductory tutorials, and
creating a new feature that works in a fundamentally different way but
has the *exact same name*, is, in my opinion, just a bad idea. If the
core team was determined to dump the old scaffold, they should have
replaced the generator output with a message that you should use
scaffold_resource instead, and explain that it works differently.

Of course this is all water under the bridge, and I suppose I
shouldn''t complain since it gives an advantage to sites such as mine
that will have current tutorials, but I hope the core team thinks
about the unnecessary pain this caused for many people trying to learn
the platform the next time they consider redefining what a feature
does. Please don''t reuse existing names to make them do different
things in silent and confusing ways.

Michael Slater
www.BuildingWebApps.com
www.LearningRails.com

On Feb 24, 10:38 am, "s.ross"
<cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Feb 24, 2008, at 4:33 AM, tonypm wrote:
>
> > So many of
> > the tutorials are now going to just not work for Rails 2 and are going
> > to point in the wrong direction, particularly as regards REST (and
> > consequently the scaffold) and routing which is getting a fairly high
> > profile.
>
> @tonypm--
>
> These changes cannot have come as a surprise to anyone who was
> tracking Rails. As with anything that has a good deal of Internet
> buzz, some of that buzz will not be updated to reflect the news.
> Still, the benefits of extracting certain functionality from Rails
> core was articulated very early. It is not the fault of the Rails core
> team that so much of the existing information you can turn up using
> Google focuses on earlier versions of Rails.
>
> Several blogs have meticulously tracked the changes as Rails core has
> merged them into edge:
>
> http://ryandaigle.com/http://blog.hasmanythrough.com/
>
> Are two good places to look. I single these two out, not because they
> are the only places to look, but rather because they are the first
> that come to mind. I even wrote a post on upgrading to Rails 2.0 that
> addressed dynamic scaffolding:
>
> http://calicowebdev.com/blog/show/17
>
> The regrettable thing about this is that dynamic scaffolding was such
> an eye-popping feature that people got used to highlighting it as an
> example of the true productivity one might achieve using Rails. In
> practice, many Rails 1.x (if not most) developers wound up creating
> their own actions and views to replace the dynamic scaffolds, yet the
> code remained in the Rails codebase. That became, essentially, dead
> code in the production codebase. Yet is cost time for the core team to
> maintain. There are other dynamic scaffold solutions available, and
> while not covered exhaustively in the "how-to''s" that
are so pervasive
> on the Web, they may do an even better job that Rails'' original
one.
>
> Pagination is another place that may disappoint. But Rails pagination
> was not considered a great solution. Many, many posts to this list
> complained about poor performance. Several replacements have emerged
> that are superior, the most popular being will_paginate
(http://errtheblog.com
> ). Another one is paginating_find
(http://cardboardrocket.com/pages/paginating_find
> ), which I''ve used to good effect in some applications.
>
> I encourage you to consider the Rails core team a limited resource and
> ask yourself whether you would prefer they spend their time keeping up
> with legacy features (even though there are better alternatives for
> them) or pushing forward.
>
> My $.02
--~--~---------~--~----~------------~-------~--~----~
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 for taking the time to reply.  Actually,  I want to apologize
about my post.  It was one of those you regret as soon as you push the
send button.  I really like Ruby and Rails.  I must have had a
frustrating day I guess.

I agree with you that it is important that the core team focus on the
development of the project.   If the way Rails is being developed is
what results in Rails being just so good - then who am I to complain?

One thing I have decided to do is to keep more abreast of the
discussions on where Rails is heading and why, but I''m not sure at the
moment where that sort of discussion might be visible.  Is there such
a thing as a core team discussion forum that is visible to the general
surfer - or is it a case of subscribing to some key blogs?

Tonypm

On Feb 24, 6:38 pm, "s.ross"
<cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Feb 24, 2008, at 4:33 AM,tonypmwrote:
>
> > So many of
> > the tutorials are now going to just not work for Rails 2 and are going
> > to point in the wrong direction, particularly as regards REST (and
> > consequently the scaffold) and routing which is getting a fairly high
> > profile.
>
> @tonypm--
>
> These changes cannot have come as a surprise to anyone who was
> tracking Rails. As with anything that has a good deal of Internet
> buzz, some of that buzz will not be updated to reflect the news.
> Still, the benefits of extracting certain functionality from Rails
> core was articulated very early. It is not the fault of the Rails core
> team that so much of the existing information you can turn up using
> Google focuses on earlier versions of Rails.
>
> Several blogs have meticulously tracked the changes as Rails core has
> merged them into edge:
>
> http://ryandaigle.com/http://blog.hasmanythrough.com/
>
> Are two good places to look. I single these two out, not because they
> are the only places to look, but rather because they are the first
> that come to mind. I even wrote a post on upgrading to Rails 2.0 that
> addressed dynamic scaffolding:
>
> http://calicowebdev.com/blog/show/17
>
> The regrettable thing about this is that dynamic scaffolding was such
> an eye-popping feature that people got used to highlighting it as an
> example of the true productivity one might achieve using Rails. In
> practice, many Rails 1.x (if not most) developers wound up creating
> their own actions and views to replace the dynamic scaffolds, yet the
> code remained in the Rails codebase. That became, essentially, dead
> code in the production codebase. Yet is cost time for the core team to
> maintain. There are other dynamic scaffold solutions available, and
> while not covered exhaustively in the "how-to''s" that
are so pervasive
> on the Web, they may do an even better job that Rails'' original
one.
>
> Pagination is another place that may disappoint. But Rails pagination
> was not considered a great solution. Many, many posts to this list
> complained about poor performance. Several replacements have emerged
> that are superior, the most popular being will_paginate
(http://errtheblog.com
> ). Another one is paginating_find
(http://cardboardrocket.com/pages/paginating_find
> ), which I''ve used to good effect in some applications.
>
> I encourage you to consider the Rails core team a limited resource and
> ask yourself whether you would prefer they spend their time keeping up
> with legacy features (even though there are better alternatives for
> them) or pushing forward.
>
> My $.02
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

sorry, I should have acknowledged the bloggs you already mentioned.  I
have now subscribed to err.the_blog, I currently use will_paginate,
but will  take a look at paginating_find.

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

OK - so I''m having a bad day and hit send before I''d
finished!!

I should have added that:

http://ryandaigle.com/
http://blog.hasmanythrough.com/
http://calicowebdev.com/blog

look to be really good resources that I have now subscribed to:

I agree with you about avoiding scaffolding.  Actually, I tend to keep
a sample scaffold to hand as a ''for example'', but
that''s about all.  I
note your the reference in your blog to make_resourceful.  I suspect
there may well be times when this could make life easier.

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

Baz,

You don''t have to read very far into this thread to realize that most
of the responders, and most of the developers making decisions about
Rail''s long term direction, are consultants or independent software
houses working on de novo apps, just like 37Signals. So, you may not
get many replies to your question:
> But seriously, how does one "import" and already existing
database design
> into a Rails Project? I''m talking about 100+ tables, with (on
average) 20+
> fields.
because that''s not a problem for them. Obviously, the old
introspecting scaffold that responded to existing tables is of little
interest for them; in their world, the tables don''t exist until they
are designing their app, or they are just tweaking an app they''ve
already written.

So, anyone who questions the elimination of the old-school scaffolding
is assumed to be a newbie trying to avoid learning the framework.

Enterprise developers, who don''t have the luxury of designing from the
ground up, are just a tiny minority in the Rails world. I''m afraid
that decisions like this one will be the pattern for some time to
come. If they had made the "introspecting scaffolding" a plug-in, I
might have thought the needs of enterprise developers were at least
considered, but they completely eliminated it so it dies without a
whimper. Maybe the framework will be strong enough to find use in the
enterprise anyway, and maybe not.
>For me, web development is about getting stuff done.
Yeah, me, too. I''ve been using the RoR framework for nearly two years;
I''m not a newbie; I''m perfectly comfortable writing
controllers. Like
you, I''ve inherited some tables with a jillion columns, and it is far
faster to delete some auto-generated code than to type in all those
column names/types.

So, here''s a thread that actually addresses your concern:
http://groups.google.com/group/rubyonrails-talk/browse_frm/thread/6b745a5475b29231/15335cc35b8e90ad?hl=en&lnk=gst&q=scaffolding#
Brian Hogan has a gem that will scaffold the forms, at least.
http://scaffoldform.rubyforge.org/

I modified his scaffoldform to make a generator that does something
similar for the show and index pages as well. It''s not quite ready for
prime time, but it works for what I need.

It is called scaffold_reflect: you put it where Rails expects to find
generators and then use scaffold_reflect TableName and it makes index,
show, edit form, and new form pages for the table, with every field
(except _id fields) represented by a reasonable  HTML entity. Similar
to the old-school scaffolding, except that every field is spelled out
there ready to modify or delete. No need to type in the structure of a
table that already exists, right?

If you''re interested, send me an email and I''ll package it up
for you
and send it on. Even with its little peculiarities, it is a lot faster
than the new scaffolding for an existing table.

Ron
--~--~---------~--~----~------------~-------~--~----~
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''m not apposed to learning the framework. Truth be told, I
don''t even know
Ruby yet. But, as I said before, the scaffolding generation functionality
that I''ve seen in other frameworks, has been invaluable to me learning
the
framework.

But, I suppose this is one step further to ensuring that people use
migrations.

But, then I''m still confused. What is the point of script/generate
then? Why
make a view with fields? Since these changes are incremental, won''t it
just
overwrite the that view for the next migration change you make? Or are you
supposed to relist ALL fields PLUS additional for every new generation?

Or maybe all these questions will be revealed to me much later after I
finish Agile Web Dev. and take a hefty look at the chapter on Migrations?

But then again, this was written for 1.2, so who knows?
--
Baz L
Just thinking aloud.

On Mon, Feb 25, 2008 at 7:38 AM, paron
<rphillips-Gbsd49wXnelcb8pDYxsr+SzEyWLYDCHU@public.gmane.org>
wrote:
>
> Baz,
>
> You don''t have to read very far into this thread to realize that
most
> of the responders, and most of the developers making decisions about
> Rail''s long term direction, are consultants or independent
software
> houses working on de novo apps, just like 37Signals. So, you may not
> get many replies to your question:
>
> > But seriously, how does one "import" and already existing
database
> design
> > into a Rails Project? I''m talking about 100+ tables, with (on
average)
> 20+
> > fields.
>
> because that''s not a problem for them. Obviously, the old
> introspecting scaffold that responded to existing tables is of little
> interest for them; in their world, the tables don''t exist until
they
> are designing their app, or they are just tweaking an app they''ve
> already written.
>
> So, anyone who questions the elimination of the old-school scaffolding
> is assumed to be a newbie trying to avoid learning the framework.
>
> Enterprise developers, who don''t have the luxury of designing from
the
> ground up, are just a tiny minority in the Rails world. I''m afraid
> that decisions like this one will be the pattern for some time to
> come. If they had made the "introspecting scaffolding" a plug-in,
I
> might have thought the needs of enterprise developers were at least
> considered, but they completely eliminated it so it dies without a
> whimper. Maybe the framework will be strong enough to find use in the
> enterprise anyway, and maybe not.
>
> >For me, web development is about getting stuff done.
>
> Yeah, me, too. I''ve been using the RoR framework for nearly two
years;
> I''m not a newbie; I''m perfectly comfortable writing
controllers. Like
> you, I''ve inherited some tables with a jillion columns, and it is
far
> faster to delete some auto-generated code than to type in all those
> column names/types.
>
> So, here''s a thread that actually addresses your concern:
>
>
http://groups.google.com/group/rubyonrails-talk/browse_frm/thread/6b745a5475b29231/15335cc35b8e90ad?hl=en&lnk=gst&q=scaffolding#
> Brian Hogan has a gem that will scaffold the forms, at least.
> http://scaffoldform.rubyforge.org/
>
> I modified his scaffoldform to make a generator that does something
> similar for the show and index pages as well. It''s not quite ready
for
> prime time, but it works for what I need.
>
> It is called scaffold_reflect: you put it where Rails expects to find
> generators and then use scaffold_reflect TableName and it makes index,
> show, edit form, and new form pages for the table, with every field
> (except _id fields) represented by a reasonable  HTML entity. Similar
> to the old-school scaffolding, except that every field is spelled out
> there ready to modify or delete. No need to type in the structure of a
> table that already exists, right?
>
> If you''re interested, send me an email and I''ll package
it up for you
> and send it on. Even with its little peculiarities, it is a lot faster
> than the new scaffolding for an existing table.
>
> Ron
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Sorry Ron, forgot to add:

Your reply was much appreciated.

On Mon, Feb 25, 2008 at 7:38 AM, paron
<rphillips-Gbsd49wXnelcb8pDYxsr+SzEyWLYDCHU@public.gmane.org>
wrote:
>
> Baz,
>
> You don''t have to read very far into this thread to realize that
most
> of the responders, and most of the developers making decisions about
> Rail''s long term direction, are consultants or independent
software
> houses working on de novo apps, just like 37Signals. So, you may not
> get many replies to your question:
>
> > But seriously, how does one "import" and already existing
database
> design
> > into a Rails Project? I''m talking about 100+ tables, with (on
average)
> 20+
> > fields.
>
> because that''s not a problem for them. Obviously, the old
> introspecting scaffold that responded to existing tables is of little
> interest for them; in their world, the tables don''t exist until
they
> are designing their app, or they are just tweaking an app they''ve
> already written.
>
> So, anyone who questions the elimination of the old-school scaffolding
> is assumed to be a newbie trying to avoid learning the framework.
>
> Enterprise developers, who don''t have the luxury of designing from
the
> ground up, are just a tiny minority in the Rails world. I''m afraid
> that decisions like this one will be the pattern for some time to
> come. If they had made the "introspecting scaffolding" a plug-in,
I
> might have thought the needs of enterprise developers were at least
> considered, but they completely eliminated it so it dies without a
> whimper. Maybe the framework will be strong enough to find use in the
> enterprise anyway, and maybe not.
>
> >For me, web development is about getting stuff done.
>
> Yeah, me, too. I''ve been using the RoR framework for nearly two
years;
> I''m not a newbie; I''m perfectly comfortable writing
controllers. Like
> you, I''ve inherited some tables with a jillion columns, and it is
far
> faster to delete some auto-generated code than to type in all those
> column names/types.
>
> So, here''s a thread that actually addresses your concern:
>
>
http://groups.google.com/group/rubyonrails-talk/browse_frm/thread/6b745a5475b29231/15335cc35b8e90ad?hl=en&lnk=gst&q=scaffolding#
> Brian Hogan has a gem that will scaffold the forms, at least.
> http://scaffoldform.rubyforge.org/
>
> I modified his scaffoldform to make a generator that does something
> similar for the show and index pages as well. It''s not quite ready
for
> prime time, but it works for what I need.
>
> It is called scaffold_reflect: you put it where Rails expects to find
> generators and then use scaffold_reflect TableName and it makes index,
> show, edit form, and new form pages for the table, with every field
> (except _id fields) represented by a reasonable  HTML entity. Similar
> to the old-school scaffolding, except that every field is spelled out
> there ready to modify or delete. No need to type in the structure of a
> table that already exists, right?
>
> If you''re interested, send me an email and I''ll package
it up for you
> and send it on. Even with its little peculiarities, it is a lot faster
> than the new scaffolding for an existing table.
>
> Ron
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 25 Feb 2008, at 13:38, paron wrote:
> So, anyone who questions the elimination of the old-school scaffolding
> is assumed to be a newbie trying to avoid learning the framework.
>
> Enterprise developers, who don''t have the luxury of designing from
the
> ground up, are just a tiny minority in the Rails world. I''m afraid
> that decisions like this one will be the pattern for some time to
> come. If they had made the "introspecting scaffolding" a plug-in,
I
> might have thought the needs of enterprise developers were at least
> considered, but they completely eliminated it so it dies without a
> whimper. Maybe the framework will be strong enough to find use in the
> enterprise anyway, and maybe not.
It was made into a plugin :
http://dev.rubyonrails.org/browser/plugins/scaffolding
There are also much nicer looking alternatives such as activescaffold

Fred

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

Again I say, scaffolding is a confusing term use. I''m referring to the
scaffolding that generates code.

I am totally with everyone, when they say that the auto scaffolding feature
is a bit useless. Fine for a quick demo, but ....



On Mon, Feb 25, 2008 at 10:27 AM, Frederick Cheung <
frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On 25 Feb 2008, at 13:38, paron wrote:
>
> > So, anyone who questions the elimination of the old-school scaffolding
> > is assumed to be a newbie trying to avoid learning the framework.
> >
> > Enterprise developers, who don''t have the luxury of designing
from the
> > ground up, are just a tiny minority in the Rails world. I''m
afraid
> > that decisions like this one will be the pattern for some time to
> > come. If they had made the "introspecting scaffolding" a
plug-in, I
> > might have thought the needs of enterprise developers were at least
> > considered, but they completely eliminated it so it dies without a
> > whimper. Maybe the framework will be strong enough to find use in the
> > enterprise anyway, and maybe not.
>
> It was made into a plugin :
> http://dev.rubyonrails.org/browser/plugins/scaffolding
> There are also much nicer looking alternatives such as activescaffold
>
> Fred
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> It was made into a plugin
:http://dev.rubyonrails.org/browser/plugins/scaffolding
> There are also much nicer looking alternatives such as activescaffold
>
> Fred
Is that really where people are expected to go to get plugins? How do
they find it? I googled pretty extensively, but didn''t see it. Is
there some link somewhere beside this thread?

Well, I''m glad the plugin''s out there, at least, even if
there''s no
way to find it without wading through a half-dozen lectures about how
"scaffolds are bad" and implying "only a lazy, shallow developer
would
even ask."

Thank you for answering the question. It will probably cost you some
''Rails cool guy'' points. However, if your response, or one of
the few
others like it, had come before all the sermons, it would have left a
very much more attractive picture of the Rails community.

Ron
--~--~---------~--~----~------------~-------~--~----~
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 25, 2008, at 5:38 AM, paron wrote:
> So, anyone who questions the elimination of the old-school scaffolding
> is assumed to be a newbie trying to avoid learning the framework.
>
> Enterprise developers, who don''t have the luxury of designing from
the
> ground up, are just a tiny minority in the Rails world. I''m afraid
> that decisions like this one will be the pattern for some time to
> come. If they had made the "introspecting scaffolding" a plug-in,
I
> might have thought the needs of enterprise developers were at least
> considered, but they completely eliminated it so it dies without a
> whimper. Maybe the framework will be strong enough to find use in the
> enterprise anyway, and maybe not.
You may or may not be correct about the logic behind extracting  
dynamic scaffolding. I would ask that you consider several resources  
before drawing too many conclusions:

http://dev.rubyonrails.org (in particular
ghttp://dev.rubyonrails.org/changeset/6306
, where you can see that the extraction of dynamic scaffolding from  
edge happened almost a *year* ago)

http://activescaffold.com/ (a capable -- some might even say "sexy" --
plugin for creating nice interfaces to your models)

http://magicmodels.rubyforge.org/ (Dr Nic''s magic models, which give  
you the luxury to support the 200 tables in your legacy database with  
very little programmer interaction)

I am having a hard time viewing the Rails community as one with a  
narrow perspective that forecloses various aspects of Web development.  
One key to working with open source tools as opposed to, say, .Net or  
J2EE, is that you have to spend the time to watch what''s going on in  
the community.

I don''t mean to pick on you specifically, but all the complaints about
scaffolding breaking tutorials, or worse making Rails inappropriate  
for certain categories of development was something that was discussed  
and decided many moons ago. It shouldn''t be a shocker, and I would  
suggest that the tutorials should share the responsibility of staying  
current.

This is all opinion on my part, so take it with a grain of salt :)

--~--~---------~--~----~------------~-------~--~----~
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 25, 2008, at 9:10 AM, paron wrote:
>
>
>> It was made into a plugin
:http://dev.rubyonrails.org/browser/plugins/scaffolding
>> There are also much nicer looking alternatives such as activescaffold
>>
>> Fred
>
> Is that really where people are expected to go to get plugins? How do
> they find it? I googled pretty extensively, but didn''t see it. Is
> there some link somewhere beside this thread?
>
> Well, I''m glad the plugin''s out there, at least, even if
there''s no
> way to find it without wading through a half-dozen lectures about how
> "scaffolds are bad" and implying "only a lazy, shallow
developer would
> even ask."
>
> Thank you for answering the question. It will probably cost you some
> ''Rails cool guy'' points. However, if your response, or
one of the few
> others like it, had come before all the sermons, it would have left a
> very much more attractive picture of the Rails community.
>
> Ron
You may be interested to note that when 2.x was released and people  
initially felt the pain, I went to the trouble of putting a post on  
this mailing list detailing the issues (http://www.ruby-forum.com/topic/138533 
). As I say in the post, I don''t use scaffolding, but I am sympathetic
to those who are just coming up to speed so I wrote what I could  
discover about scaffolding.

It feels just a little unfair to hear the Rails community  
characterized as one that awards "Rails cool guy" points. This subject
has been discussed on the ML several times and while I don''t  
discourage further discussion, using the context of previous  
information put forward on the same subject can be useful and perhaps  
save a bit of time.

I don''t think "only a lazy shallow developer would even ask,"
but I do
think a responsible developer should evaluate existing and viable  
options before complaining that the scaffold system is gone, leaving a  
void that somehow makes Rails less usable. A good deal of hard work  
has gone into making the existing scaffolding (script/generate  
scaffold) follow the RESTful conventions. Further, much hard work has  
gone into plugins such as ActiveScaffold, will_paginate,  
paginating_find, etc.

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

s. ross --
Our posts crossed in the mails, making mine look like an especially
combative reply to yours, which was not my intent. Please let me try
again.
> You may be interested to note that when 2.x was released and people
> initially felt the pain, I went to the trouble of putting a post on
> this mailing list detailing the issues
(http://www.ruby-forum.com/topic/138533
> ). As I say in the post, I don''t use scaffolding, but I am
sympathetic
> to those who are just coming up to speed so I wrote what I could
> discover about scaffolding.
Any of the links you sent would have been a fine reply to the OP or to
Baz, as would Frederick''s. Then, perhaps, all those sermons, if people
felt they were necessary.

> It feels just a little unfair to hear the Rails community
> characterized as one that awards "Rails cool guy" points. This
subject
> has been discussed on the ML several times and while I don''t
> discourage further discussion, using the context of previous
> information put forward on the same subject can be useful and perhaps
> save a bit of time.
Agreed, it would have been much more to the point if some of the
earlier posters had done that. I''d have traded one post with an on-
topic page slap for all the lectures.
> I don''t think "only a lazy shallow developer would even
ask," but I do
> think a responsible developer should evaluate existing and viable
> options before complaining that the scaffold system is gone, leaving a
> void that somehow makes Rails less usable. A good deal of hard work
> has gone into making the existing scaffolding (script/generate
> scaffold) follow the RESTful conventions. Further, much hard work has
> gone into plugins such as ActiveScaffold, will_paginate,
> paginating_find, etc.
I freely admit that many people a great deal smarter than me worked
very hard on the decisions and the code. Their decisions and code make
a great deal of sense from the POV of a developer working from a blank
db or a db they''ve developed using migrations, perhaps.

However, from the (limited) POV of a developer stuck with the task of
hanging a web front end on 100+ existing tables of 20+ columns each,
hand-coding 2000+ field name/type combos was a tremendous step
backward. Going back to the old scaffolding was a not-unreasonable
question from his POV,  and he''s not alone.

Thanks again for the links, and the research you did. Believe me, that
plugin is not easy for a newbie or even a fairly oldbie to find. Those
links will make it easier for people to choose for themselves which
approach makes sense.

Ron
--~--~---------~--~----~------------~-------~--~----~
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''m a complete n00by on rails ATM, started learning sometime 2 days
ago.
The following is not the best of tutorials but hopefully it should help 
someone like myself and save them the time and trouble.

Disclaimer: I''m presuming you are on windows since that''s the 
troublemaker in the bunch. I''m also presuming some prerequisites have 
been met, namely: you have mysql with a root password (it''s okey to
have
none, just ignore a step bellow),  I''m also presuming you have ruby
(and
commands such as ruby work for you). Since it''s in context
I''ll also
presume you have rails 2.0.2 installed, or some other version of rails 
from the ("cursed" by the user base) 2.0.x series.

-- rails 1.2.6

The instructions provided (and repeated) in a few of the posts above 
generally won''t work. At least for me installing rails 1.2.6 while
still
holding onto 2.0.2 and it''s dependencies proved a major head ache,
thing
simply won''t work to the fullest, just like the scaffold 
method/generator.

To run on rails 1.2.6 and play & watch the famous blog in 15 minutes 
video, do the following. (''#'' mark comments, ignore them;
they''re likely
to cause errors)

# uninstall everything, like this...
gem uninstall rails
# if you have multiple version a prompt will appear,
# simply uninstall everything! and re-install, like so
gem install rails --version 1.2.6 --include-dependencies

You can now go through everything and have fun.
Basic round down, the dynamic scaffold thing apparently has no other use 
then to generate table in which it places the fields of the database 
tables (excepting :id) under the format: <b>NameField:</b> 
<field-appropriate-tag /> int crappy tr/td tags. Note how the <b>
tag is
deprecated and is just a style thing not a semantic tag. This behavior 
is reflected in the currently available static scaffold, which pretty 
much makes both of them not very impressive in my eyes.

-- rails 2.0.2 or perhaps later version
(blog in 15minutes equivalent tutorial)

- short version -----
# Blog in 30s
# You are root with password ''''
rails -d mysql ruby_log
cd ruby_log
rake db:create
ruby script/generate scaffold Post title:string created_at:datetime 
updated_at:datetime body:text
rake db:migrate
ruby script/server

# The other stuff works as well, but really doesn''t change the
semantics
much.
# Customize the view to your hearts content.
# has_many, has_one, belongs_to

- long version ------
Before I start detailing commands and movie parts I would just like to 
point out that the movie seems to be aimed at the very beginner and some 
parts (I suspect) were deliberately shown as they were so as to not make 
the public feel like total strangers.

Let''s get it started.
If you don''t already installed then I "suggest"
(it''s not a requirement)
you install cygwin, it will give you most of the useful linux commands, 
if you wish you should be able to run the scripts as in the movie with 
the ./ notation instead of calling ruby. Just a suggestion.

* movie scene
# how I did it/ commented out line
> command line
* creating a blog

# we want a mysql database, so...
> rails -d mysql ruby_log
# see more commands by just typing "rails"

# navigate to the root of your project
> cd ruby_log
# extra: something I always use when programs have logs.
# First, open a cygwin window, navigate down
# find your project root directory
# Now use tail -f on the useful logs, for example
> tail -f log/development.log
# now you see all the SQL as it''s made
# you can change to test etc depending on your needs

# Go to and open ''config/database.yml''
# Insert your password in there.
# execute the following to get a few useful files up
# create the database:
> rake db:create
# create a schema file
# if it''s empty then this is the first time you used
# tried to make a project with this name, if not
# the command failed (showed you squat, but check the log)
# you''ve just dumped the old schema (tables & table
structure)
> rake db:schema:dump
# Tip. You generally have a corresponding ''destroy'' method for
# any create/generate method you have, for example:
# > rake db:drop
# > ruby script/destroy model Post

* he creates a Blog controller and shows you how to
* use render :text => "something" or View to show things
* he creates index.rhtml for the demonstration

# I created a index.html.erb (.erb is the new convention for
# rails files), it has to be ''index'' btw, naming it
''view'' etc
# won''t work.

* he demonstrates the ''scaffold :post'' method

# Skip. it''s useless, unnecessary etc

* he then uses the scaffold generate directive to create a
* scaffold.
* > ./script/generate scaffold Post Blog

# that''s the do-thingy that just won''t work
# I should note he makes note in a few places that scaffolding
# is anything but rails and the misconception is widespread

# I''ll continue through the commands at this point in time

// Migrations:
# But first, a side note:
# If you want to create a "model", then don''t do it as he did
it!
# Use migrations!
# Either:
> ruby script/generate model User
# just as a example. Go to db/migrations,
# there should be only one there (insert things like this in there:
# t.string :nick, :name, :type
# ^ this creates 3 columns (nick, name, type all of type string)
# to create the database entry run
> rake db:migrate
# you can also create migrations by themselves
> ruby script/generate migration AddSignature
# go to 002_.... in migrations and add something like this to .up
#   alter_table :users do |t|
#     t.text :signature
#   end
# and to .down
#   drop_column :signature
# Now migrate from v1 to v2
> rake db:migrate
# your users now have a new column: "signature"
# if you migrate down, say go to v1
> rake db:migrate VERSION=1
# now column ''signature'' doesn''t exist anymore
# of course previous signature data has been lost also!
# if you want to start with your databases empty, run
# > rake db:migrate VERSION=0
# if you want to wipe them out, presumably intending to
# delete the project files as well, run:
# > rake db:drop
# we don''t want table "users" to complete the videos
objective so do a:
> ruby script/destroy model User
// End migration explanation

# The old ''scaffold'' entry was somewhat more flexible, it
would
# read the databases model of the specified table, and then
# display them in the order the were in the database.
# You could also modify the database and see changes live.

# The new one is no longer live and you no longer specify an
# existing method, instead it''s a macro for creating a:
# Model, Migration (Model --> Database thing), Controller & View
# complete with comments and useful methods.
# To create the do-post-thingy in the video write as
follows:
> ruby script/generate scaffold Post title:string created_at:datetime
updated_at:datetime body:text
# update database to latest version
> rake db:migrate
# start server
> ruby script/server
# wait for it to boot...

Go to http://localhost:3000/posts and check out this blog in 60s
(just think how fast you can copy/paste from here)

---- My newbie opinion --

I feel it''s unnecessary, I don''t hold any grudge since
I''m used every
dev-thing kicking me in the balls at one point or another. It''s
honestly
poor work and defect thinking. If it works and it isn''t hurting
anybody,
don''t hurt the community by removing it. It''s honestly
useless, a piece
of nothing, I think it''s over-praised and over-bashed, it''s
not that
defective and not that important. It could have been dealt with as a 
impassible error, a "won''t go production with it",
I''m sure other
elegant solutions also exist. Hiding it simply makes people want; people 
who would have used it would know it''s useless.

I don''t really buy into Ron''s argument. If you are troubled
inserting 20
or so fields, as key:value pairs then I, presented with this situation, 
would have to consider the following: what is the significance/condition 
of the fields that would result in such a large number, is it 
outdated/deprecated/insignificant or simply easily generated data? can I 
simplify, re-structure or back it up safely and deal with it later? Is 
it end user form info?, in which case the question becomes: If *I* have 
so much trouble inserting key:value (20 per table was it?) just what am 
I asking my end users to do? (since they have to insert more complex 
data)

Steven G. Harms 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/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.net/?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
-- 
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-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
-~----------~----~----~----~------~----~------~--~---

Hi --

On Wed, 2 Jan 2008, Steven G. Harms 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.
I don''t think this is exactly the philosophical area you were asking
about, but my biggest problem with the new scaffolding is that it
reinforces the notion that a "resource" is a controller/model stack.
That, in turn, means that it discourages recognition of those cases
where a resource might involve something other than a one-to-one
correspondence between a controller and a model.

In REST, there''s nothing about the concept of "resource" that
implies
database persistence, or persistence at all for that matter. Of
course, Rails is a database-centered technology, not an all-purpose
embodiment of every nuance of "resource". Still, I think the
scaffolding presents too monogamous a picture of controller/model
relations, if I may put it that way. The result is that people worry
that if they do something in one controller that involves two models,
they''ve done something "unRESTful". That''s a red
herring.

Mind you, it can be extremely productive to think about CRUD
operations in the controller as a kind of tail-wagging-the-dog way (in
a good sense) of refining your modeling: that is, having a Borrowing
model and a borrowings controller with a create action, instead of a
users controller with a borrow_book action. But sometimes it''s not a
whole package; sometimes you might want the CRUD controller part
without a persistent model. *Something* has been making people have a
hard time thinking along those lines, or suspecting that there''s
something wrong with doing so; and while there''s probably no single
cause, my impression is that the new-style scaffolding has something
to do with it.


David

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!

--~--~---------~--~----~------------~-------~--~----~
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 don''t really buy into Ron''s argument. If you are
troubled inserting 20
> or so fields, as key:value pairs then I, presented with this situation,
> would have to consider the following: what is the significance/condition
> of the fields that would result in such a large number, is it
> outdated/deprecated/insignificant or simply easily generated data? can I
> simplify, re-structure or back it up safely and deal with it later? Is
> it end user form info?, in which case the question becomes: If *I* have
> so much trouble inserting key:value (20 per table was it?) just what am
> I asking my end users to do? (since they have to insert more complex
> data)
If it were only 20 fields, I might have said the same. It was not --
he had 100+ tables of 20+ fields each -- or 2000+ field:value pairs.
He specifically said that they were legacy tables, so all your
(perfectly valid) db design critique is beside the point. The users
already insert that complex data, or have already done so (if it''s a
decision support db, as I suspect.)

So, given those conditions, I stand by my position that a scaffolding
that introspects the table was the best answer. Too bad it was
eliminated from the Rails defaults without providing a clear path to
replace it.
--~--~---------~--~----~------------~-------~--~----~
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 24, 8:55 pm, Michael Slater
<m...-04BUtanlfE1BDgjK7y7TUQ@public.gmane.org>
wrote:
> I''ve spoken with a lot of people who are in the process of
learning
> Rails, and I believe the core team made a big mistake in removing the
> basic scaffold and renaming scaffold_resource to scaffold.
Michael, to double on your $0.02...

I am a Rails newbie. I''ve touched lightly on various tutorials and
books on previous releases on Rails 2.0 before, and I came back to
Rails 2.0 to really really learn it this time. When I saw the REST
presentation by DHH I thought "hey, I don''t need it, I just want
to
learn Rails". The big changes in the scaffolding generator and other
bits have confused me at first, precisely because I didn''t take the
changes seriously.

However, as far as I could tell, Rails now makes it really hard to
deviate from RESTful approach, and that forces me, the newbie, to
stick to it. I don''t have skills to hack the way around REST, and that
makes my webapp restful. And that, I think, was the main point of
changes introduced in Rails 2.0.

The only thing I''m missing now is a few more tutorials, but once I got
a bit more familiar with the shining new Rails, Akita''s tutorial made
a lot more sense, and I was able to learn a lot from it.

Also, I''d like to say this again (and people have said it before in
this topic): we are using Rails to write code, are we not? And
learning about code, for me, is easiest when looking at actual code,
not some ''scaffold'' line. Just looking at the default scaffold
generator''s code was a great learning experience. So, I suggest to all
newbies: forget the tutorials from Rails 1.x era, and stop fighting
the new RESTful design. RESTful design is so much simpler after you
grasp the basics, and you actually write code, which is, imvho much
more rewarding than all that magic and 15-minute app that doesn''t do
quite what you need.

Best regards,

Branko
--~--~---------~--~----~------------~-------~--~----~
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 think you have a point, David -- look at all the discussions (Rails
groups AND ReST groups, both) about "search." There''s no
guarantee
that you''ll get the same response from a given search over time. In
fact, you shouldn''t; otherwise, you should just cache the page and
call it a ''result'' or something.

I was confused about it; Roy Fielding (I think it was) explained it
like this: a resource is like your P. O. Box; you know where it is; it
never changes; and the postal workers know where it is, it never
changes. But, what you''ll find in there? Whatever the postal workers
think is appropriate. The analogy is imperfect, because you can''t do
content negotiation at your P.O.Box. Imagine if you could say, "I only
want first-class mail, please, no bulk mailings, English versions if
available" and then the analogy is pretty good, I think.

My very first ReST Web Service was written in Python, and serves
geographic conversions for Northern Ohio. (GeoGeeks: available at
http://uber.engineer.co.summit.oh.us/ws/spc3401/ ) There''s no real
reason to expect anyone to request any given resource more than once,
so it''s not a database, it''s just a calculation. It''s
not very browser
oriented. It also doesn''t do CRUD -- just "R." If
I''d learned Rails
2.0 scaffolding first, I might have had even more "unlearning" to do
before I got straightened around.

Rails 2.0 is "ReSTish" and that''s good, but it''s
still browserfied.
The adaptation of ReST to the browser by Rails is very, very clever,
but perhaps a little distracting. Interested people might look at
http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html for
an example of why providing a ReST Web Service shouldn''t be conflated
(mentally) with manipulating it via the browser.

Ron


On Mar 3, 7:51 am, "David A. Black"
<dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org>
wrote:
> Hi --
>
> On Wed, 2 Jan 2008, Steven G. Harms 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.
>
> I don''t think this is exactly the philosophical area you were
asking
> about, but my biggest problem with the new scaffolding is that it
> reinforces the notion that a "resource" is a controller/model
stack.
> That, in turn, means that it discourages recognition of those cases
> where a resource might involve something other than a one-to-one
> correspondence between a controller and a model.
>
> In REST, there''s nothing about the concept of "resource"
that implies
> database persistence, or persistence at all for that matter. Of
> course, Rails is a database-centered technology, not an all-purpose
> embodiment of every nuance of "resource". Still, I think the
> scaffolding presents too monogamous a picture of controller/model
> relations, if I may put it that way. The result is that people worry
> that if they do something in one controller that involves two models,
> they''ve done something "unRESTful". That''s a
red herring.
>
> Mind you, it can be extremely productive to think about CRUD
> operations in the controller as a kind of tail-wagging-the-dog way (in
> a good sense) of refining your modeling: that is, having a Borrowing
> model and a borrowings controller with a create action, instead of a
> users controller with a borrow_book action. But sometimes it''s not
a
> whole package; sometimes you might want the CRUD controller part
> without a persistent model. *Something* has been making people have a
> hard time thinking along those lines, or suspecting that there''s
> something wrong with doing so; and while there''s probably no
single
> cause, my impression is that the new-style scaffolding has something
> to do with it.
>
> David
>
> --
> Upcoming Rails training from David A. Black and Ruby Power and Light:
>    ADVANCING WITH RAILS, April 14-17 2008, New York City
>    CORE RAILS, June 24-27 2008, London (Skills Matter)
> Seehttp://www.rubypal.comfor details. Berlin dates coming soon!
--~--~---------~--~----~------------~-------~--~----~
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 Mon, Mar 3, 2008 at 7:07 AM, foxbunny
<bg.branko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> However, as far as I could tell, Rails now makes it really hard to
> deviate from RESTful approach, and that forces me, the newbie, to
> stick to it. I
>
 This just described why I think scaffolding is bad. It indirectly forces
newcomers to do things a specific way.  If you use the scaffolding, you
start building controllers based off the code there.  If you learned to
create a controller and views without the scaffolding, you''d be more
free to
do things as you see fit.

Railes substitues proper "getting started" documentation for
scaffolded code
generation which makes it really tough on newcomers.   People who''ve
been
doing Rails as long as I have don''t really care because we
don''t use
scaffolding. However, I work with newbies all the time and it''s much
easier
to start them on Rails 1.x and move to Rails 2.0 and REST later. The
original scaffold generator was very good for explaining how controllers
work with models and views. link_to used a hash and not a named route. Named
routes are cool, but they are confusing to a newbie. Same with respond_to.

The only upshot for Rails 2.0 scaffolding is that it''s much more
production-ready.

--~--~---------~--~----~------------~-------~--~----~
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 Mar 3, 10:47 am, "Brian Hogan"
<bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>  it''s much easier
> to start them on Rails 1.x and move to Rails 2.0 and REST later.
This suggestion worries me a little, because I have found that the
conversion is not simple.

If version 2.0 is compellingly superior to 1.x, then newbies should
start there.  (Using the latest stable version is a long-standing
tradition in software, because it is effective.)  Nothing in this long
and useful discussion thread suggests that the RoR developers are
inclined to add the feature that is being discussed to an upcoming
version.  And so there is a simple choice: use RoR 2.0 as it is, or
choose another framework.  (This second option is not meant to be
heretical; newbies should be aware that there are alternatives.)

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

Hi --

On Mon, 3 Mar 2008, dankelley wrote:
>
> On Mar 3, 10:47am, "Brian Hogan"
<bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>  it''s much easier
>> to start them on Rails 1.x and move to Rails 2.0 and REST later.
>
> This suggestion worries me a little, because I have found that the
> conversion is not simple.
>
> If version 2.0 is compellingly superior to 1.x, then newbies should
> start there.  (Using the latest stable version is a long-standing
> tradition in software, because it is effective.)  Nothing in this long
> and useful discussion thread suggests that the RoR developers are
> inclined to add the feature that is being discussed to an upcoming
> version.  And so there is a simple choice: use RoR 2.0 as it is, or
> choose another framework.  (This second option is not meant to be
> heretical; newbies should be aware that there are alternatives.)
Keep in mind, though, that Rails 2.0 is in this respects a superset of
1.x. You don''t have to use the RESTful facilities if you don''t
want to
(and you certainly don''t have to use the scaffolding). I would agree
with Brian in spirit but I''d put it slightly differently: it''s
easier
to start with the non-REST stuff and then learn the REST stuff, but
all of this can be done in the context of 2.0, i.e., it''s not
specifically a 1.x vs. 2.0 thing.

In training people in Rails, I definitely do not start with REST and
resources. map.resources is essentially a macro that creates a bunch
of named routes for you -- so if you don''t know what a named route is,
you can only do it in a black-box and parrot-like way. Learning named
routes doesn''t make much sense until you understand routes, and routes
don''t make sense until you know the basics of the request cycle... and
so forth. So I would never introduce someone to Rails by telling them
to write map.resources in routes.rb and trying to proceed from there.


David

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

I think part of the problem is that "scaffolding" should not be part
of any Rails developer''s vocabulary.  Scaffolding is too limiting and
"opinionated" to be useful in 99% of real-world applications.  Not to
mention all the RESTful issues that David A. Black has already
mentioned.  You can''t really be RESTful AND be scaffolding.

In my humble opinion, "scaffolding" is the marketing tool to convince
people to check Rails out.  I know it worked on me a few years back.
But, for most, it will quickly become forgotten.

Just my thoughts.

On Mar 3, 9:42 am, "David A. Black"
<dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org>
wrote:
> Hi --
>
>
>
> On Mon, 3 Mar 2008, dankelley wrote:
>
> > On Mar 3, 10:47 am, "Brian Hogan"
<bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>  it''s much easier
> >> to start them on Rails 1.x and move to Rails 2.0 and REST later.
>
> > This suggestion worries me a little, because I have found that the
> > conversion is not simple.
>
> > If version 2.0 is compellingly superior to 1.x, then newbies should
> > start there.  (Using the latest stable version is a long-standing
> > tradition in software, because it is effective.)  Nothing in this long
> > and useful discussion thread suggests that the RoR developers are
> > inclined to add the feature that is being discussed to an upcoming
> > version.  And so there is a simple choice: use RoR 2.0 as it is, or
> > choose another framework.  (This second option is not meant to be
> > heretical; newbies should be aware that there are alternatives.)
>
> Keep in mind, though, that Rails 2.0 is in this respects a superset of
> 1.x. You don''t have to use the RESTful facilities if you
don''t want to
> (and you certainly don''t have to use the scaffolding). I would
agree
> with Brian in spirit but I''d put it slightly differently:
it''s easier
> to start with the non-REST stuff and then learn the REST stuff, but
> all of this can be done in the context of 2.0, i.e., it''s not
> specifically a 1.x vs. 2.0 thing.
>
> In training people in Rails, I definitely do not start with REST and
> resources. map.resources is essentially a macro that creates a bunch
> of named routes for you -- so if you don''t know what a named route
is,
> you can only do it in a black-box and parrot-like way. Learning named
> routes doesn''t make much sense until you understand routes, and
routes
> don''t make sense until you know the basics of the request cycle...
and
> so forth. So I would never introduce someone to Rails by telling them
> to write map.resources in routes.rb and trying to proceed from there.
>
> David
>
> --
> Upcoming Rails training from David A. Black and Ruby Power and Light:
>    ADVANCING WITH RAILS, April 14-17 2008, New York City
>    CORE RAILS, June 24-27 2008, London (Skills Matter)
> Seehttp://www.rubypal.comfor details. Berlin dates coming soon!
--~--~---------~--~----~------------~-------~--~----~
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 Mon, Mar 3, 2008 at 11:20 AM, Fred
<lee.fred.1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> But, for most, it will quickly become forgotten.

Judging from the response to this thread, I doubt it will be forgotten soon
as many many many newcomers seem to crave the old school scaffolding, if
only because 98% of tutorials out there use it to hype how Rails is magic
and not work.

_My_ two cents.

RSL

--~--~---------~--~----~------------~-------~--~----~
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 Mar 3, 3:47 pm, "Brian Hogan"
<bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>  This just described why I think scaffolding is bad. It indirectly forces
> newcomers to do things a specific way.  If you use the scaffolding, you
> start building controllers based off the code there.  If you learned to
> create a controller and views without the scaffolding, you''d be
more free to
> do things as you see fit.
Well, it''s not just scaffolding. Rails is a framework, not a general
purpose programming language, very specific to the goals it was
created to achieve. As such it is meant to behave one way or the other
until you decide to hack it. I think that for a newbie it is more
important to limit the choices and learn one way of doing things. If s/
he is diligent enough, Rails can always be made to do things
differently, or you can simply _not_ use Rails at all. That, with
respect to what Brian said, is the way I feel framework should work:
limiting choices instead of flooding you with unnecessary
abstractions.

Besides, I think this is not a problem with how scaffolding works in
general, but the transition between the non-REST and RESTful
scaffolder.
> Railes substitues proper "getting started" documentation for
scaffolded code
> generation which makes it really tough on newcomers.   People
who''ve been
> doing Rails as long as I have don''t really care because we
don''t use
> scaffolding. However, I work with newbies all the time and it''s
much easier
> to start them on Rails 1.x and move to Rails 2.0 and REST later. The
> original scaffold generator was very good for explaining how controllers
> work with models and views. link_to used a hash and not a named route.
Named
> routes are cool, but they are confusing to a newbie. Same with respond_to.
Well, you have to admit that may not apply to all newcomers. As for
myself, I believe I would have grasped the new way of working much
faster have I not used Rails before. It is, admittedly, a bit harder
to find tutorials for 2.0 at this moment, but that is changing
rapidly. In a few months, I think a newcomer will find it much easier
to start with Rails 2.0.
--~--~---------~--~----~------------~-------~--~----~
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 Mar 3, 2008, at 7:42 AM, David A. Black wrote:
> Rails 2.0 is in this respects a superset of
> 1.x. You don''t have to use the RESTful facilities
First, thank you David for your insights regarding REST and immutable  
resources. Second, I think the major pain point is that Rails 2.0 is  
not a proper superset (or rather 1.x is not a proper subset). They  
more overlap, and places where this is most evident is dynamic  
scaffolding and pagination.

Rails does, indeed, encourage RESTful design to the point where you  
have to work around it if you don''t conceptualize your application in  
that manner. Rails is opinionated. We get that. And the opinion is  
that if you can''t use the REST verbs and a cluster of controllers to  
describe your application as a set of resources you need to re-examine  
your design. Heretically, I sometimes feel that twisting my design  
around a post to make it RESTful is not the best use of my client''s  
money.

On the scaffolding/pagination issue, there are ways to make 2.0x  
behave similarly to 1.x by installing the extracted plugins. If you''re
a newbie, it is not evident that you have to do this, but after some  
Googling ways to make 2.0x can build the Depot app. On the application  
design philosophy issue, that''s baked in at a routing level and you  
get the joy of working around the (IMO) screwiest part of Rails to  
tweak: Routes.

But, if your opinion is too divergent from Rails, there are merb and a  
number of other up-and-coming frameworks that reserve some opinion.

--~--~---------~--~----~------------~-------~--~----~
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 David - you and I are in complete agreement. I didn''t mean to
state
that I explicitly use Rails 1.x... I just use Rails 1.x *concepts* like
classic routing, non-REST controllers, etc when we''re starting out.

On Mon, Mar 3, 2008 at 9:42 AM, David A. Black
<dblack-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi --
>
> On Mon, 3 Mar 2008, dankelley wrote:
>
> >
> > On Mar 3, 10:47 am, "Brian Hogan"
<bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>  it''s much easier
> >> to start them on Rails 1.x and move to Rails 2.0 and REST later.
> >
> > This suggestion worries me a little, because I have found that the
> > conversion is not simple.
> >
> > If version 2.0 is compellingly superior to 1.x, then newbies should
> > start there.  (Using the latest stable version is a long-standing
> > tradition in software, because it is effective.)  Nothing in this long
> > and useful discussion thread suggests that the RoR developers are
> > inclined to add the feature that is being discussed to an upcoming
> > version.  And so there is a simple choice: use RoR 2.0 as it is, or
> > choose another framework.  (This second option is not meant to be
> > heretical; newbies should be aware that there are alternatives.)
>
> Keep in mind, though, that Rails 2.0 is in this respects a superset of
> 1.x. You don''t have to use the RESTful facilities if you
don''t want to
> (and you certainly don''t have to use the scaffolding). I would
agree
> with Brian in spirit but I''d put it slightly differently:
it''s easier
> to start with the non-REST stuff and then learn the REST stuff, but
> all of this can be done in the context of 2.0, i.e., it''s not
> specifically a 1.x vs. 2.0 thing.
>
> In training people in Rails, I definitely do not start with REST and
> resources. map.resources is essentially a macro that creates a bunch
> of named routes for you -- so if you don''t know what a named route
is,
> you can only do it in a black-box and parrot-like way. Learning named
> routes doesn''t make much sense until you understand routes, and
routes
> don''t make sense until you know the basics of the request cycle...
and
> so forth. So I would never introduce someone to Rails by telling them
> to write map.resources in routes.rb and trying to proceed from there.
>
>
> David
>
> --
> Upcoming Rails training from David A. Black and Ruby Power and Light:
>   ADVANCING WITH RAILS, April 14-17 2008, New York City
>   CORE RAILS, June 24-27 2008, London (Skills Matter)
> See http://www.rubypal.com for details. Berlin dates coming soon!
>  >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

What I meant was that the developer would quickly forget about it.  In
others word, I can''t remember the last time I ran a scaffold
generation.  It just is not useful in most cases.

But, for those new to it, it will continue to be a drawing factor.

On Mar 3, 10:30 am, "Russell Norris"
<r...-ftMzyaTR+bHNyFkoKTPOtdi2O/JbrIOy@public.gmane.org>
wrote:
> On Mon, Mar 3, 2008 at 11:20 AM, Fred
<lee.fre...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > But, for most, it will quickly become forgotten.
>
> Judging from the response to this thread, I doubt it will be forgotten soon
> as many many many newcomers seem to crave the old school scaffolding, if
> only because 98% of tutorials out there use it to hype how Rails is magic
> and not work.
>
> _My_ two cents.
>
> RSL
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Fred wrote:
> What I meant was that the developer would quickly forget about it.  In
> others word, I can''t remember the last time I ran a scaffold
> generation.  It just is not useful in most cases.
> 
> But, for those new to it, it will continue to be a drawing factor.
Thanks.  my construction scaffold is : http://www.direct-scaffold.com
-- 
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-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
-~----------~----~----~----~------~----~------~--~---

Well, this is not scaffolding but it can help with getting a quick start 
in rails with established database schemata:

views/model/new.html.erb

<%- content_tag_for :h2, @model do %>
  Adding Model <%= @model.id.to_s -%>
<%- end -%>

<%= error_messages_for :model -%>

<%= form :model -%>         <== this generates an entire data entry
html
form
                                from the database attributes
<%= link_to ''Back'', model_path %>


See ActionView::Helpers::ActiveRecordHelper form method
-- 
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-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
-~----------~----~----~----~------~----~------~--~---

As someone who only wips out rails every once in a while to create a new 
project, I always got my refresh from scaffolding then editing the 
generated code.  I learned 80% of what I needed to know from that.  The 
fact that dynamic scaffolding was removed is both frustrating and 
depressing.

Damn you!
-- 
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-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
-~----------~----~----~----~------~----~------~--~---

Alex Williams wrote:
> [...] scaffolding then editing the 
> generated code [...]  The 
> fact that dynamic scaffolding was removed is both frustrating and 
> depressing.
> 
> Damn you!
No, it''s not. This is getting mildly frustrating.

If you were editing the generated code you''ve been using static 
scaffolding, i.e. script/scaffold. That''s still there. Dynamic 
scaffolding OTOH is waving CRUD methods and views out of thin air by 
writing a line in the controller. That one is gone.

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

Maybe what Alex really means to complain about is the "introspection"
part of the old-style scaffolding (e.g., it would sniff an existing db
table for attributes rather than force you to list them out on the
script/generate command line)?  Losing that is a legit beef IMHO.

I''ve not tried this one myself, but it looks promising:

http://www.elctech.com/blog/refreshing-rails-generated-views

Here''s another approach--it''s working for me, but is not
rigorously
tested or anything:

http://helloimbloggingatyounow.blogspot.com/2008/03/i-am-leet-rails-haxor.html

HTH,

-Roy

On Apr 18, 2:40 pm, Johannes Holzer
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Alex Williams wrote:
> > [...] scaffolding then editing the
> > generated code [...]  The
> > fact that dynamic scaffolding was removed is both frustrating and
> > depressing.
>
> > Damn you!
>
> No, it''s not. This is getting mildly frustrating.
>
> If you were editing the generated code you''ve been using static
> scaffolding, i.e. script/scaffold. That''s still there. Dynamic
> scaffolding OTOH is waving CRUD methods and views out of thin air by
> writing a line in the controller. That one is gone.
>
> --
> Posted viahttp://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-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
-~----------~----~----~----~------~----~------~--~---

Philosophically, the name scaffold was chosen early on to suggest a
temporary structure upon which you can lean as you start building but
one which you intend to take down as the main structure begins to
sustain itself.  In that regard the 2.x implementation is more sound
philosophically: the scaffold exists in the early stages of
development in a way that will always go away over time.  Having a
''scaffold'' command was a mistake because it gave the temporary
structure a permanence that it was never intended to have.

On Feb 25, 4:23 am, tonypm
<tonypmar...-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
wrote:
> sorry, I should have acknowledged the bloggs you already mentioned.  I
> have now subscribed to err.the_blog, I currently use will_paginate,
> but will  take a look at paginating_find.
>
> Tonypm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Roy Pardee wrote:
> Maybe what Alex really means to complain about is the
"introspection"
> part of the old-style scaffolding (e.g., it would sniff an existing db
> table for attributes rather than force you to list them out on the
> script/generate command line)?  Losing that is a legit beef IMHO.
> 
> I''ve not tried this one myself, but it looks promising:
> 
> http://www.elctech.com/blog/refreshing-rails-generated-views
> 
> Here''s another approach--it''s working for me, but is not
rigorously
> tested or anything:
> 
>
http://helloimbloggingatyounow.blogspot.com/2008/03/i-am-leet-rails-haxor.html
> 
> HTH,
> 
> -Roy
> 
> On Apr 18, 2:40 pm, Johannes Holzer
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
Roy is right,

my DB will be constantly expanding and taking on change. As I will never 
know what new thing will need to be added.  This makes static 
scaffolding very irritating. I also hate long long commands at the 
command line, I ALWAYS am making mistakes when writing those.

It shouldn''t be hard to understand that re-learning rails via generated
code that actually worked when you changed your db made for a very 
pleasant re-learning process, with static scaffolding that has become 
quite the frustration.

Please understand that the scaffold command was easily abused, but that 
was the agile and comfortable part for new users and people who need a 
little refresh like myself.

Thank you,

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

Alex Williams wrote:
> Roy Pardee wrote:
>> Maybe what Alex really means to complain about is the
"introspection"
>> part of the old-style scaffolding (e.g., it would sniff an existing db
>> table for attributes rather than force you to list them out on the
>> script/generate command line)?  Losing that is a legit beef IMHO.
>> 
>> I''ve not tried this one myself, but it looks promising:
>> 
>> http://www.elctech.com/blog/refreshing-rails-generated-views
>> 
>> Here''s another approach--it''s working for me, but is
not rigorously
>> tested or anything:
>> 
>>
http://helloimbloggingatyounow.blogspot.com/2008/03/i-am-leet-rails-haxor.html
>> 
>> HTH,
>> 
>> -Roy
>> 
>> On Apr 18, 2:40 pm, Johannes Holzer
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> 
> Roy is right,
> 
> my DB will be constantly expanding and taking on change. As I will never 
> know what new thing will need to be added.  This makes static 
> scaffolding very irritating. I also hate long long commands at the 
> command line, I ALWAYS am making mistakes when writing those.
> 
> It shouldn''t be hard to understand that re-learning rails via
generated
> code that actually worked when you changed your db made for a very 
> pleasant re-learning process, with static scaffolding that has become 
> quite the frustration.
> 
> Please understand that the scaffold command was easily abused, but that 
> was the agile and comfortable part for new users and people who need a 
> little refresh like myself.
> 
> Thank you,
> 
> Alex
To be clear I am not talking about just putting in a controller:

scaffold :foo

I''m talking about the old:

script/server generate scaffold foo

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