On Mon, Mar 3, 2008 at 7:07 AM, foxbunny [email protected] 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.
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
On Mar 3, 10:47 am, “Brian H.” [email protected] 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.)
Hi –
On Mon, 3 Mar 2008, dankelley wrote:
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!
On Mon, Mar 3, 2008 at 11:20 AM, Fred [email protected] 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
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, 3:47 pm, “Brian H.” [email protected] 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.
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.
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.
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
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.
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
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!
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.
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:
HTH,
-Roy
On Apr 18, 2:40 pm, Johannes H. [email protected]
Roy P. 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:
Elctech.com is for sale | HugeDomains
Here’s another approach–it’s working for me, but is not rigorously
tested or anything:
Hello, I'm blogging at you now...: I am a leet rails haxor...
HTH,
-Roy
On Apr 18, 2:40 pm, Johannes H. [email protected]
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
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.
Alex Williams wrote:
Roy P. 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:
Elctech.com is for sale | HugeDomains
Here’s another approach–it’s working for me, but is not rigorously
tested or anything:
Hello, I'm blogging at you now...: I am a leet rails haxor...
HTH,
-Roy
On Apr 18, 2:40 pm, Johannes H. [email protected]
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