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
--
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/
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/.
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
--
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
--
> 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
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/
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 | ja...@restphone.com
Ruby and Ruby on Rails consulting
blog.restphone.com
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.
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...@gmail.com>
> 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
> 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.
It was made into a plugin : http://dev.rubyonrails.org/browser/plugins/scaffolding
There are also much nicer looking alternatives such as activescaffold
Fred
> 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.
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 :)
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 (http://www.ruby-forum.com/topic/138533
). 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.
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:
> 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
On Wed, 2 Jan 2008, Steven G. 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.
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
--
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!
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
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!
But, for most, it will quickly become forgotten.
> 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.
Thanks. my construction scaffold is : http://www.direct-scaffold.com
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
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.
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