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

[Brian Hogan]

On Mon, Mar 3, 2008 at 7:07 AM, foxbunny <bg.branko@...> 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@...
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
-~----------~----~----~----~------~----~------~--~---

[Dan Kelley]

On Mar 3, 10:47 am, "Brian Hogan" <bpho...@...> 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@...
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
-~----------~----~----~----~------~----~------~--~---

[Fred-117]

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

> Hi --
>
>
>
> On Mon, 3 Mar 2008, dankelley wrote:
>
> > On Mar 3, 10:47 am, "Brian Hogan" <bpho...@...> 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@...
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
-~----------~----~----~----~------~----~------~--~---

[Russell Norris]

On Mon, Mar 3, 2008 at 11:20 AM, Fred <lee.fred.1@...> 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@...
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
-~----------~----~----~----~------~----~------~--~---

[foxbunny]

On Mar 3, 3:47 pm, "Brian Hogan" <bpho...@...> 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@...
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
-~----------~----~----~----~------~----~------~--~---

[s.ross]

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

[Brian Hogan]

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

Hi --

On Mon, 3 Mar 2008, dankelley wrote:

>
> On Mar 3, 10:47 am, "Brian Hogan" <bpho...@...> 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@...
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
-~----------~----~----~----~------~----~------~--~---

[Fred-117]

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

> On Mon, Mar 3, 2008 at 11:20 AM, Fred <lee.fre...@...> 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@...
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]

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

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

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

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

[Roy Pardee]

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

[AndyV-4]

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

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

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

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