Rails 3 : basic routes

Hi,

When you generate a new Rails 3 project, "basic" routes are disabled
by default because this line is commented out :
# match ':controller(/:action(/:id(.:format)))'

Is it really necessary?
What about people learning Rails who are not familiar with REST?

It was so easy to teach beginners : just create a controller, an
action, a view, open the corresponding URL and you get your hello
world. And you get all of this by convention, you don't have to
configure anything!

Ok now they just have to uncomment the previous line of code in
routes.rb to get this example working.
But shouldn't we go the opposite way by letting advanced developers
comment this line out by themselves if they don't need it?

What's your opinion about this?

Cheers,

Anthony

Hey Anthony,

Great observation here. The only thing I would say is to define
"beginners" and how you want to teach them. We're all being pushed
towards a more RESTful design - both by Rails and by web development
in general. So it seems that a framework has to make a decision - do
we make it easy for beginners or do we promote best practices,
"convention", and what we believe in? I actually think Rails 3 is
doing all of those. Just remember - we were all "beginners", and our
skills were honed by what we were forced to work with. :slight_smile:

Trey

I agree with Trey. People learning Rails should be learning the
conventions, not the exceptions. As for the learning curve, I think it
is simple enough to generate a scaffold.

Allen Madsen
http://www.allenmadsen.com

The catch-all route let to a series of faulty patterns such a
hide_action and verification. At it's core, the router is the
appropriate place to limit request that go onto the controllers.

In this case, removing the default route allows us to simplify the
explanation of how you should go about "hiding actions" or
"restricting an action to GET".

The catch-all route let to a series of faulty patterns such a
hide_action and verification. At it's core, the router is the
appropriate place to limit request that go onto the controllers.

Agreed. Many a 2.x production app spews exceptions about being hit
with invalid routes, with no easy way to stop it. It'll be great if
there's an easy convention to prevent this.

In this case, removing the default route allows us to simplify the
explanation of how you should go about "hiding actions" or
"restricting an action to GET".

Does this updated simplified explanation exist yet?

Thanks,
-- Chad

The default routes are the first thing that have to go in all my apps.

A beginner will most likely use a generator for his controllers
and that will create proper resource routes.

ciao, tom

I've been using Rails to teach web application development at the
University level since 2005. The very first thing we do in the section
about routing is entirely zero out the routes.rb file to be an empty
routing block.

This comes from several semesters of working with default routes
available and having nearly half the class end up with a false
association that urls *must* match controller/action names. Even after
explaining REST, building custom routes, and working with
map.resources a significant number of students would cling to their
first understanding of routing (the defaults) and never move away from
them.

The magic of map.resources can suffer from the same problem: students
understand its outcome (urls of a certain pattern) earlier than its
intended use (urls for a certain type of resource) and often abuse
map.resources just to get urls they want (e.g. map.resource :about_us
just to get a url "/about_us").

To stray slightly off topic:
Initially we taught Rails using all the handy shortcuts used to make
development faster and have slowly moved towards a more hands on,
fundamentals approach to instruction in the framework. Topics we
typically don't cover until the students understand the patterns
behind them:
  * default routes (we never explain this)
  * map.resource/s (mentioned after they've been hand-crafting the
REST pattern in routes)
  * generators (mentioned in passing after they've created files they
need by hand)
  * form builders, form helpers (we never cover these at all).
  * ERB (we've had more luck with haml)

When I mention this at conferences I get reactions I'd expect from
insulting someone's mother but the abstraction of form builders or
generators are great for rapid development but a pedagogic nightmare
(and ERB is a typing error minefield without helpers).

-Trek