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

[Steven G. Harms]

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

[Jeremy McAnally]

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

[Steven G. Harms]

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

[Adam Akhtar-2]

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

[Jeremy McAnally]

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

[ebenezer]

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

[Jeremy McAnally]

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

[ebenezer]

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

[Xavier Noria]

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

[Rick DeNatale]

On Jan 2, 2008 4:11 PM, Xavier Noria <fxn@...> 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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Moore-7]

On Jan 2, 2008 12:20 PM, fredistic <fredistic@...> 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@...
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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Adam Akhtar-2]

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

[thbar]

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

[Martin Westin]

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

[Adam Akhtar-2]

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

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

[Baz L]

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

[Ryan Bigg-2]

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

[dasil003-2]

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

[Dave Porter-3]

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

[Baz L]

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