Deprecate dynamic scaffolding

[Josh Peek]

I want to raise some discussion on whether dynamic scaffolding should
be deprecated or not?

I don't think it has any real production value. I've seen examples of
improving dynamic scaffolding to work better with resources, but I
don't think they belong in core. If anything, dynamic scaffolding
would serve better as a plugin.

Anyone agree?

[Tim Lucas]

How about getting rid of scaffolding altogether? Narr... they're good
as an example of how to use the framework, that is, assuming they're
updated as the framework gets updated and best practices evolve.

If scaffolding's purpose is for learning purposes only, maybe is
should be stated as such:

./script/generate example_controller

?

-- tim

[Dave Thomas]

On Mar 1, 2007, at 11:25 PM, Tim Lucas wrote:

>> I don't think it has any real production value. I've seen examples of
>> improving dynamic scaffolding to work better with resources, but I
>> don't think they belong in core. If anything, dynamic scaffolding
>> would serve better as a plugin.

It can be useful for the maintenance of things like lookup tables,
particularly during development.

Dave

[Kevin Clark]

I agree. Scaffolding is about having something to learn from. If
you're learning from it, you need the code. If you're building from
it, you should have the code. Dynamic scaffolding is just for flash.

+1 for deprecation

--
Kevin Clark
http://glu.ttono.us

[matthew clark]

agreed, however, when the goal is to expose a resource, then dynamic
scaffolding may be good enough.

[Wayne E. Seguin]

+1 This should be in a plugin, it only adds extra code to rails.

~Wayne

[Wayne E. Seguin]

On Mar 02, 2007, at 00:33 , Dave Thomas wrote:
> It can be useful for the maintenance of things like lookup tables,
> particularly during development.
>
> Dave

True, but this can just as easily be facilitated as a plugin.

~Wayne

[Tom Ward]

Yet another +1. I'd like it deprecated within the framework, it's
much better suited as a plugin.

Tom

[Alexey Verkhovsky]

Yet another +1.  I'd like it deprecated within the framework, it's
much better suited as a plugin.

+1

And if you need something quick and [not quite as] dirty for an admin interface, streamlined [http://www.streamlinedframework.org/pages/about ] does a much better job than dynamic scaffolding.

Alex

[Istvan Hoka]

+1

--
Istvan Hoka

[Justin Forder]

I see that lots of people are agreeing, but please bear in mind that the
second edition of AWDR starts work on the Depot application by using
dynamic scaffolding. The first edition did not.

Deprecating dynamic scaffolding will give the impression to AWDR2
readers, just when they are starting to work with Rails against a
database, that Rails is not stable.

regards

Justin Forder

[DHH]

> I want to raise some discussion on whether dynamic scaffolding should
> be deprecated or not?

This is already on the agenda for Rails 2.0. I fully agree that this
would make a great plugin, though. Even better, it'd make a great 5
plugins. Each targeted at different uses of it.
--
David Heinemeier Hansson

[Wayne E. Seguin]

Excellent point. Perhaps this should be kept in the current core and
be pulled for 2.0 which the next book (?) will address.

~Wayne

[Jeff]

What was meant by 'dynamic' scaffolding? If we're talking about
removing the scaffold generator, then I'm against it. Many people
learn a lot from generating the scaffolding for a controller and then
reading the generated code. I'd hate to make them learn how to
install plugins first.

If you're instead referring to the 'scaffold' class method that can be
used in a controller, then I'm all for removing it :-)

Jeff
softiesonrails.com

[Michael Koziarski]

> Deprecating dynamic scaffolding will give the impression to AWDR2
> readers, just when they are starting to work with Rails against a
> database, that Rails is not stable.

Any major changes will be held back till 2.0. There's definitely no
intention of breaking people's scaffolds in 1.2.3.

While I'm probably the most paranoid core-team member when it comes to
backwards compatibility, I'd still rather see the framework continue
to evolve, rather than stagnate indefinitely to satisfy some people's
fear of change :). Eventually that feature will be pulled out to a
plugin, but for this release stream, it's fine where it is.

--
Cheers

Koz

[Josh Peek]

On Mar 2, 12:50 pm, "DHH" <david.heineme...@gmail.com> wrote:
> This is already on the agenda for Rails 2.0. I fully agree that this
> would make a great plugin, though. Even better, it'd make a great 5
> plugins. Each targeted at different uses of it.

Shall I put in a patch/ticket to add a deprecation warning to
"scaffold"?

[Rob Sanheim]

Big plus +1 here. Dynamic scaffold == bad. Static == very good for
newbies and learning.

- rob

[Manfred Stienstra]

On Mar 2, 2007, at 11:24 PM, Rob Sanheim wrote:
> Big plus +1 here. Dynamic scaffold == bad. Static == very good for
> newbies and learning.

+1, with the recent ReSTfullization I've also found that many
controllers look the same and the static scaffolding has found it's
place again.

Manfred

[Josh Peek]

See ticket #7700 (http://dev.rubyonrails.org/ticket/7700).

[Michael Koziarski]

> Shall I put in a patch/ticket to add a deprecation warning to
> "scaffold"?

When something's deprecated, there's generally got to be something
quick and easy the user can do about it. Change @flash to flash, etc.
No point shouting at the user if the action they have to take is long
and laborious.

We should mark it is deprecated in the documentation, then make sure
that come 2.0 there's a plugin they can install for the same
functionality.

--
Cheers

Koz

[Josh Peek]

On Mar 2, 2007, at 4:44 PM, Michael Koziarski wrote:

> We should mark it is deprecated in the documentation, then make sure
> that come 2.0 there's a plugin they can install for the same
> functionality.

I'll jump on the plugin. Should I commit it to the official plugin
repository or just to my own?

[Josh Peek]

Just finished rolling the scaffolding plugin. I would deprecate
scaffolding in core and point people to install the plugin instead.
The plugin will then override the annoying deprecation notice.

The plugin is a direct port, no new enhancements, even though it could
use some. O, and for the first time, scaffolding tests!

http://dev.rubyonrails.org/attachment/ticket/7700/scaffolding_plugin.diff

[Tim Connor]

On Mar 3, 7:40 pm, "Josh Peek" <j...@joshpeek.com> wrote:
> The plugin is a direct port, no new enhancements, even though it could
> use some. O, and for the first time, scaffolding tests!
>

I'm not maintaining it anymore, but I did create a full dynamic
resource scaffolding plugin, last year, that you are welcome to borrow
from, if there is anything worth it in there:
http://code.google.com/p/dynamic-scaffold-resource/ . I followed the
existing scaffolding code (that existed at that time, obviously), as
closely as I could.

After making that plugin I started to come around to the core team's
views on the shortcomings of scaffolding, but I still don't like the
lack of DRYness of how much shared code there is between my
controllers. Maybe the generator should create a shared
restcontroller to inherit from? Basically an updated version of
http://geekonomics.blogspot.com/2006/07/crud-and-shared-controllers.html
That allows for DRYness with the flexibility to easily override,
customize, and extend.

Not sure if there is any interest in doing so in core, so I went ahead
and did so for my own use, but it's MIT licensed, so have at it. ;) I
just think the move to REST simplifies things enough that they can be
DRYed out even more.

http://code.google.com/p/restcontroller/
http://www.timocracy.com/articles/2007/04/03/dynamic-scaffold-resource-is-dead-long-live-restcontroller