DRYing up link_to

In reading DHH's post about RC1, it dawned on me that we could
potentially DRY up link_to even more. Notice the redundancy in the
examples in the docs?*

  link_to "Delete this page", { :action => "delete", :id => @page.id },
:confirm => "Are you sure?"
  link_to "Help", { :action => "help" }, :popup => true
  link_to "Busy loop", { :action => "busy" }, :popup => ['new_window',
'height=300,width=600']
  link_to "Destroy account", { :action => "destroy" }, :confirm => "Are
you sure?", :post => true

All of these could be rewritten without the action parameter, since
action = name.split(' ').first.downcase, which could give us elegant
statements like this:

  link_to "Help", :popup => true

What are your thoughts?

* I modified the first doc example to use a delete action instead of
destroy to more clearly illustrate the idea

D. Scott Brown wrote:

All of these could be rewritten without the action parameter, since
action = name.split(' ').first.downcase, which could give us elegant
statements like this:

link_to "Help", :popup => true

What are your thoughts?

I'm gonna go write linky() to do that and call link_to().

(Aphorism: There is no "DRY" in API!)

You're assumign the link name corresponds to the action, which is a
pretty big assumption.

link_to "remove post", { :action => "delete",...}
link_to "read post", { :action => "show", ...}
etc...

Fine for a plugin, but definitely not baked in.

- rob

Keynan Pratt wrote:

allow me to point out that you should be using button_to for the
delete/destroy action

Perhaps someone could correct that in the docs?

We're also assuming that the table names correspond to model names,
which is a pretty big assumption. Just like in ActiveRecord, you'd
still be able to manually specify an :action, but this seems like a
textbook case where Rails can again leverage intelligent defaults.

D. Scott Brown wrote:

Keynan Pratt wrote:

> allow me to point out that you should be using button_to for the
> delete/destroy action

Perhaps someone could correct that in the docs?

I think it's a semantic distinction. Like the hallowed CUA used to say
"a dialog box is for brief interaction, such as presenting one
question to the user". Then we'd use one to occupy the "form" concept,
and some dipshit consultant would catch us and ask us if we read the
CUA. When we gave it to him with shrink-wrap on it, my colleague said,
"Well, we read it, but then we put the shrinkwrap back on it."

Where was I? Oh, yeah - destructive actions should - semantically - be
behind buttons and POSTs, not A HREFs and GETs.