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