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

@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://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 (Welcome cardboardrocket.com - BlueHost.com), 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

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

Thanks for taking the time to reply. Actually, I want to apologize about my post. It was one of those you regret as soon as you push the send button. I really like Ruby and Rails. I must have had a frustrating day I guess.

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

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

Tonypm

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

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

I should have added that:

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

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

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

Thanks Tonypm

Baz,

You don't have to read very far into this thread to realize that most of the responders, and most of the developers making decisions about Rail's long term direction, are consultants or independent software houses working on de novo apps, just like 37Signals. So, you may not get many replies to your question:

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

because that's not a problem for them. Obviously, the old introspecting scaffold that responded to existing tables is of little interest for them; in their world, the tables don't exist until they are designing their app, or they are just tweaking an app they've already written.

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

Enterprise developers, who don't have the luxury of designing from the ground up, are just a tiny minority in the Rails world. I'm afraid that decisions like this one will be the pattern for some time to come. If they had made the "introspecting scaffolding" a plug-in, I might have thought the needs of enterprise developers were at least considered, but they completely eliminated it so it dies without a whimper. Maybe the framework will be strong enough to find use in the enterprise anyway, and maybe not.

For me, web development is about getting stuff done.

Yeah, me, too. I've been using the RoR framework for nearly two years; I'm not a newbie; I'm perfectly comfortable writing controllers. Like you, I've inherited some tables with a jillion columns, and it is far faster to delete some auto-generated code than to type in all those column names/types.

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

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

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

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

Ron

I’m not apposed to learning the framework. Truth be told, I don’t even know Ruby yet. But, as I said before, the scaffolding generation functionality that I’ve seen in other frameworks, has been invaluable to me learning the framework.

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

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

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

But then again, this was written for 1.2, so who knows?

Sorry Ron, forgot to add:

Your reply was much appreciated.

It was made into a plugin : http://dev.rubyonrails.org/browser/plugins/scaffolding There are also much nicer looking alternatives such as activescaffold

Fred

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

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

It was made into a plugin :http://dev.rubyonrails.org/browser/plugins/scaffolding There are also much nicer looking alternatives such as activescaffold

Fred

Is that really where people are expected to go to get plugins? How do they find it? I googled pretty extensively, but didn't see it. Is there some link somewhere beside this thread?

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

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

Ron

You may or may not be correct about the logic behind extracting dynamic scaffolding. I would ask that you consider several resources before drawing too many conclusions:

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

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

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

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

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

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

You may be interested to note that when 2.x was released and people initially felt the pain, I went to the trouble of putting a post on this mailing list detailing the issues (Comment: Role of Scaffolding Going Forward - Rails - Ruby-Forum). As I say in the post, I don't use scaffolding, but I am sympathetic to those who are just coming up to speed so I wrote what I could discover about scaffolding.

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

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

s. ross -- Our posts crossed in the mails, making mine look like an especially combative reply to yours, which was not my intent. Please let me try again.

You may be interested to note that when 2.x was released and people initially felt the pain, I went to the trouble of putting a post on this mailing list detailing the issues (Comment: Role of Scaffolding Going Forward - Rails - Ruby-Forum ). As I say in the post, I don't use scaffolding, but I am sympathetic to those who are just coming up to speed so I wrote what I could discover about scaffolding.

Any of the links you sent would have been a fine reply to the OP or to Baz, as would Frederick's. Then, perhaps, all those sermons, if people felt they were necessary.

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

Agreed, it would have been much more to the point if some of the earlier posters had done that. I'd have traded one post with an on- topic page slap for all the lectures.

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

I freely admit that many people a great deal smarter than me worked very hard on the decisions and the code. Their decisions and code make a great deal of sense from the POV of a developer working from a blank db or a db they've developed using migrations, perhaps.

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

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

Ron

I'm a complete n00by on rails ATM, started learning sometime 2 days ago. The following is not the best of tutorials but hopefully it should help someone like myself and save them the time and trouble.

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

-- rails 1.2.6

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

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

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

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

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

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

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

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

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

* movie scene # how I did it/ commented out line

command line

* creating a blog

# we want a mysql database, so...

rails -d mysql ruby_log

# see more commands by just typing "rails"

# navigate to the root of your project

cd ruby_log

# extra: something I always use when programs have logs. # First, open a cygwin window, navigate down # find your project root directory # Now use tail -f on the useful logs, for example

tail -f log/development.log

# now you see all the SQL as it's made # you can change to test etc depending on your needs

# Go to and open 'config/database.yml' # Insert your password in there. # execute the following to get a few useful files up # create the database:

rake db:create

# create a schema file # if it's empty then this is the first time you used # tried to make a project with this name, if not # the command failed (showed you squat, but check the log) # you've just dumped the old schema (tables & table structure)

rake db:schema:dump

# Tip. You generally have a corresponding 'destroy' method for # any create/generate method you have, for example: # > rake db:drop # > ruby script/destroy model Post

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

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

* he demonstrates the 'scaffold :post' method

# Skip. it's useless, unnecessary etc

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

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

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

// Migrations: # But first, a side note: # If you want to create a "model", then don't do it as he did it! # Use migrations! # Either:

ruby script/generate model User

# just as a example. Go to db/migrations, # there should be only one there (insert things like this in there: # t.string :nick, :name, :type # ^ this creates 3 columns (nick, name, type all of type string) # to create the database entry run

rake db:migrate

# you can also create migrations by themselves

ruby script/generate migration AddSignature

# go to 002_.... in migrations and add something like this to .up # alter_table :users do |t| # t.text :signature # end # and to .down # drop_column :signature # Now migrate from v1 to v2

rake db:migrate

# your users now have a new column: "signature" # if you migrate down, say go to v1

rake db:migrate VERSION=1

# now column 'signature' doesn't exist anymore # of course previous signature data has been lost also! # if you want to start with your databases empty, run # > rake db:migrate VERSION=0 # if you want to wipe them out, presumably intending to # delete the project files as well, run: # > rake db:drop # we don't want table "users" to complete the videos objective so do a:

ruby script/destroy model User

// End migration explanation

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

# The new one is no longer live and you no longer specify an # existing method, instead it's a macro for creating a: # Model, Migration (Model --> Database thing), Controller & View # complete with comments and useful methods. # To create the do-post-thingy in the video write as follows:

ruby script/generate scaffold Post title:string created_at:datetime updated_at:datetime body:text

# update database to latest version

rake db:migrate

# start server

ruby script/server

# wait for it to boot...

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

---- My newbie opinion --

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

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

Steven G. Harms wrote:

Hi --

Hello,

I've read the (many) re-posts about problems around scaffolding in Rails 2.0 and have followed a number of tutorials and fully understand "how to scaffold" from a technical perspective, but I don't understand the *mindset* of how to use the new scaffolding. It seems like a productivity- / agility- regress and I'm thinking I may have failed to properly grok the new setup. In the interest of full disclosure, I'm coming back to Rails after being in other toolkits for about 9 months.

I don't think this is exactly the philosophical area you were asking about, but my biggest problem with the new scaffolding is that it reinforces the notion that a "resource" is a controller/model stack. That, in turn, means that it discourages recognition of those cases where a resource might involve something other than a one-to-one correspondence between a controller and a model.

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

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

David

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

If it were only 20 fields, I might have said the same. It was not -- he had 100+ tables of 20+ fields each -- or 2000+ field:value pairs. He specifically said that they were legacy tables, so all your (perfectly valid) db design critique is beside the point. The users already insert that complex data, or have already done so (if it's a decision support db, as I suspect.)

So, given those conditions, I stand by my position that a scaffolding that introspects the table was the best answer. Too bad it was eliminated from the Rails defaults without providing a clear path to replace it.

Michael, to double on your $0.02...

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

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

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

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

Best regards,

Branko

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

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

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

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

Ron

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.