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.)
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.)
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.
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.
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.
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.
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.
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.
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.
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.
[...] 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:
Here's another approach--it's working for me, but is not rigorously
tested or anything:
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.
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:
On Apr 18, 2:40 pm, Johannes Holzer <rails-mailing-l...@andreas-s.net>
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.
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:
On Apr 18, 2:40 pm, Johannes Holzer <rails-mailing-l...@andreas-s.net>
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:
