aboutsummaryrefslogtreecommitdiffstats
path: root/actionpack/lib
diff options
context:
space:
mode:
Diffstat (limited to 'actionpack/lib')
-rw-r--r--actionpack/lib/action_controller/mime_responds.rb2
-rw-r--r--actionpack/lib/action_view/helpers/form_helper.rb84
-rw-r--r--actionpack/lib/action_view/helpers/url_helper.rb63
3 files changed, 116 insertions, 33 deletions
diff --git a/actionpack/lib/action_controller/mime_responds.rb b/actionpack/lib/action_controller/mime_responds.rb
index a17782cafc..1dbd8b9e6f 100644
--- a/actionpack/lib/action_controller/mime_responds.rb
+++ b/actionpack/lib/action_controller/mime_responds.rb
@@ -92,7 +92,7 @@ module ActionController #:nodoc:
# with the remaining data.
#
# Note that you can define your own XML parameter parser which would allow you to describe multiple entities
- # in a single request (i.e., by wrapping them all in a single root note), but if you just go with the flow
+ # in a single request (i.e., by wrapping them all in a single root node), but if you just go with the flow
# and accept Rails' defaults, life will be much easier.
#
# If you need to use a MIME type which isn't supported by default, you can register your own handlers in
diff --git a/actionpack/lib/action_view/helpers/form_helper.rb b/actionpack/lib/action_view/helpers/form_helper.rb
index b8600fe445..6d97038da9 100644
--- a/actionpack/lib/action_view/helpers/form_helper.rb
+++ b/actionpack/lib/action_view/helpers/form_helper.rb
@@ -73,30 +73,54 @@ module ActionView
# There are also methods for helping to build form tags in link:classes/ActionView/Helpers/FormOptionsHelper.html,
# link:classes/ActionView/Helpers/DateHelper.html, and link:classes/ActionView/Helpers/ActiveRecordHelper.html
module FormHelper
- # Creates a form and a scope around a specific model object that is used as a base for questioning about
- # values for the fields.
+ # Creates a form and a scope around a specific model object that is used as
+ # a base for questioning about values for the fields.
#
- # <% form_for :person, @person, :url => { :action => "update" } do |f| %>
- # <%= f.error_messages %>
- # First name: <%= f.text_field :first_name %>
- # Last name : <%= f.text_field :last_name %>
- # Biography : <%= f.text_area :biography %>
- # Admin? : <%= f.check_box :admin %>
+ # Rails provides succint resource-oriented form generation with +form_for+
+ # like this:
+ #
+ # <% form_for @offer do |f| %>
+ # <%= f.label :version, 'Version' %>:
+ # <%= f.text_field :version %><br />
+ # <%= f.label :author, 'Author' %>:
+ # <%= f.text_field :author %><br />
# <% end %>
#
- # Worth noting is that the form_for tag is called in a ERb evaluation block, not an ERb output block. So that's <tt><% %></tt>,
- # not <tt><%= %></tt>. Also worth noting is that form_for yields a <tt>form_builder</tt> object, in this example as <tt>f</tt>, which emulates
- # the API for the stand-alone FormHelper methods, but without the object name. So instead of <tt>text_field :person, :name</tt>,
- # you get away with <tt>f.text_field :name</tt>. Notice that you can even do <tt><%= f.error_messages %></tt> to display the
- # error messsages of the model object in question.
+ # There, +form_for+ is able to generate the rest of RESTful parameters
+ # based on introspection on the record, but to understand what it does we
+ # need to dig first into the alternative generic usage it is based upon.
+ #
+ # === Generic form_for
#
- # Even further, the form_for method allows you to more easily escape the instance variable convention. So while the stand-alone
- # approach would require <tt>text_field :person, :name, :object => person</tt>
- # to work with local variables instead of instance ones, the form_for calls remain the same. You simply declare once with
- # <tt>:person, person</tt> and all subsequent field calls save <tt>:person</tt> and <tt>:object => person</tt>.
+ # The generic way to call +form_for+ requires a few arguments:
#
- # Also note that form_for doesn't create an exclusive scope. It's still possible to use both the stand-alone FormHelper methods
- # and methods from FormTagHelper. For example:
+ # <% form_for :person, @person, :url => { :action => "update" } do |f| %>
+ # <%= f.error_messages %>
+ # First name: <%= f.text_field :first_name %><br />
+ # Last name : <%= f.text_field :last_name %><br />
+ # Biography : <%= f.text_area :biography %><br />
+ # Admin? : <%= f.check_box :admin %><br />
+ # <% end %>
+ #
+ # Worth noting is that the +form_for+ tag is called in a ERb evaluation block,
+ # not an ERb output block. So that's <tt><% %></tt>, not <tt><%= %></tt>. Also
+ # worth noting is that +form_for+ yields a form builder object, in this
+ # example as +f+, which emulates the API for the stand-alone FormHelper
+ # methods, but without the object name. So instead of <tt>text_field :person, :name</tt>,
+ # you get away with <tt>f.text_field :name</tt>. Notice that you can even do
+ # <tt><%= f.error_messages %></tt> to display the error messsages of the model
+ # object in question.
+ #
+ # Even further, the +form_for+ method allows you to more easily escape the
+ # instance variable convention. So while the stand-alone approach would require
+ # <tt>text_field :person, :name, :object => person</tt> to work with local
+ # variables instead of instance ones, the +form_for+ calls remain the same.
+ # You simply declare once with <tt>:person, person</tt> and all subsequent
+ # field calls save <tt>:person</tt> and <tt>:object => person</tt>.
+ #
+ # Also note that +form_for+ doesn't create an exclusive scope. It's still
+ # possible to use both the stand-alone FormHelper methods and methods from
+ # FormTagHelper. For example:
#
# <% form_for :person, @person, :url => { :action => "update" } do |f| %>
# First name: <%= f.text_field :first_name %>
@@ -105,22 +129,26 @@ module ActionView
# Admin? : <%= check_box_tag "person[admin]", @person.company.admin? %>
# <% end %>
#
- # Note: This also works for the methods in FormOptionHelper and DateHelper that are designed to work with an object as base,
- # like FormOptionHelper#collection_select and DateHelper#datetime_select.
+ # This also works for the methods in FormOptionHelper and DateHelper that are
+ # designed to work with an object as base, like FormOptionHelper#collection_select
+ # and DateHelper#datetime_select.
#
- # HTML attributes for the form tag can be given as <tt>:html => {...}</tt>. For example:
+ # HTML attributes for the form tag can be given as <tt>:html => {...}</tt>.
+ # For example:
#
# <% form_for :person, @person, :html => {:id => 'person_form'} do |f| %>
# ...
# <% end %>
#
- # The above form will then have the <tt>id</tt> attribute with the value </tt>person_form</tt>, which you can then
- # style with CSS or manipulate with JavaScript.
+ # The above form will then have the +id+ attribute with the value "person_form",
+ # which you can then style with CSS or manipulate with JavaScript.
#
# === Relying on record identification
#
- # In addition to manually configuring the form_for call, you can also rely on record identification, which will use
- # the conventions and named routes of that approach. Examples:
+ # As we said above, in addition to manually configuring the +form_for+ call,
+ # you can rely on record identification, which will use the conventions and
+ # named routes of that approach. This is the preferred way to use +form_for+
+ # nowadays:
#
# <% form_for(@post) do |f| %>
# ...
@@ -140,7 +168,7 @@ module ActionView
#
# This will expand to be the same as:
#
- # <% form_for :post, @post, :url => posts_path, :html => { :class => "new_post", :id => "new_post" } do |f| %>
+ # <% form_for :post, Post.new, :url => posts_path, :html => { :class => "new_post", :id => "new_post" } do |f| %>
# ...
# <% end %>
#
@@ -150,7 +178,7 @@ module ActionView
# ...
# <% end %>
#
- # And for namespaced routes, like admin_post_url:
+ # And for namespaced routes, like +admin_post_url+:
#
# <% form_for([:admin, @post]) do |f| %>
# ...
diff --git a/actionpack/lib/action_view/helpers/url_helper.rb b/actionpack/lib/action_view/helpers/url_helper.rb
index 375ebfcdc5..38c8d18cb0 100644
--- a/actionpack/lib/action_view/helpers/url_helper.rb
+++ b/actionpack/lib/action_view/helpers/url_helper.rb
@@ -120,17 +120,72 @@ module ActionView
# exception.
#
# ==== Examples
+ # Because it relies on +url_for+, +link_to+ supports both older-style controller/action/id arguments
+ # and newer RESTful routes. Current Rails style favors RESTful routes whenever possible, so base
+ # your application on resources and use
+ #
+ # link_to "Profile", profile_path(@profile)
+ # # => <a href="/profiles/1">Profile</a>
+ #
+ # or the even pithier
+ #
+ # link_to "Profile", @profile
+ # # => <a href="/profiles/1">Profile</a>
+ #
+ # in place of the older more verbose, non-resource-oriented
+ #
+ # link_to "Profile", :controller => "profiles", :action => "show", :id => @profile
+ # # => <a href="/profiles/show/1">Profile</a>
+ #
+ # Similarly,
+ #
+ # link_to "Profiles", profiles_path
+ # # => <a href="/profiles">Profiles</a>
+ #
+ # is better than
+ #
+ # link_to "Profiles", :controller => "profiles"
+ # # => <a href="/profiles">Profiles</a>
+ #
+ # Classes and ids for CSS are easy to produce:
+ #
+ # link_to "Articles", articles_path, :id => "news", :class => "article"
+ # # => <a href="/articles" class="article" id="news">Articles</a>
+ #
+ # Be careful when using the older argument style, as an extra literal hash is needed:
+ #
+ # link_to "Articles", { :controller => "articles" }, :id => "news", :class => "article"
+ # # => <a href="/articles" class="article" id="news">Articles</a>
+ #
+ # Leaving the hash off gives the wrong link:
+ #
+ # link_to "WRONG!", :controller => "articles", :id => "news", :class => "article"
+ # # => <a href="/articles/index/news?class=article">WRONG!</a>
+ #
+ # +link_to+ can also produce links with anchors or query strings:
+ #
+ # link_to "Comment wall", profile_path(@profile, :anchor => "wall")
+ # # => <a href="/profiles/1#wall">Comment wall</a>
+ #
+ # link_to "Ruby on Rails search", :controller => "searches", :query => "ruby on rails"
+ # # => <a href="/searches?query=ruby+on+rails">Ruby on Rails search</a>
+ #
+ # link_to "Nonsense search", searches_path(:foo => "bar", :baz => "quux")
+ # # => <a href="/searches?foo=bar&amp;baz=quux">Nonsense search</a>
+ #
+ # The three options specfic to +link_to+ (<tt>:confirm</tt>, <tt>:popup</tt>, and <tt>:method</tt>) are used as follows:
+ #
# link_to "Visit Other Site", "http://www.rubyonrails.org/", :confirm => "Are you sure?"
# # => <a href="http://www.rubyonrails.org/" onclick="return confirm('Are you sure?');">Visit Other Site</a>
#
# link_to "Help", { :action => "help" }, :popup => true
# # => <a href="/testing/help/" onclick="window.open(this.href);return false;">Help</a>
#
- # link_to "View Image", { :action => "view" }, :popup => ['new_window_name', 'height=300,width=600']
- # # => <a href="/testing/view/" onclick="window.open(this.href,'new_window_name','height=300,width=600');return false;">View Image</a>
+ # link_to "View Image", @image, :popup => ['new_window_name', 'height=300,width=600']
+ # # => <a href="/images/9" onclick="window.open(this.href,'new_window_name','height=300,width=600');return false;">View Image</a>
#
- # link_to "Delete Image", { :action => "delete", :id => @image.id }, :confirm => "Are you sure?", :method => :delete
- # # => <a href="/testing/delete/9/" onclick="if (confirm('Are you sure?')) { var f = document.createElement('form');
+ # link_to "Delete Image", @image, :confirm => "Are you sure?", :method => :delete
+ # # => <a href="/images/9" onclick="if (confirm('Are you sure?')) { var f = document.createElement('form');
# f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
# var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
# m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete Image</a>