diff options
Diffstat (limited to 'railties/guides/source/layouts_and_rendering.textile')
| -rw-r--r-- | railties/guides/source/layouts_and_rendering.textile | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/railties/guides/source/layouts_and_rendering.textile b/railties/guides/source/layouts_and_rendering.textile index 8dab578e6b..d67668df91 100644 --- a/railties/guides/source/layouts_and_rendering.textile +++ b/railties/guides/source/layouts_and_rendering.textile @@ -394,7 +394,7 @@ end Now, if the current user is a special user, they'll get a special layout when viewing a product. You can even use an inline method to determine the layout: -You can also decide the layout by passing a Proc object, the block you give the Proc will be given the +controller+ instance, so you can make decisions based on the current request. For example: +You can also decide the layout by passing a Proc object, the block you give the Proc will be given the +controller+ instance, so you can make decisions based on the current request. For example: <ruby> class ProductsController < ApplicationController @@ -572,7 +572,7 @@ With this code, the browser will make a fresh request for the index page, the co The only downside to this code, is that it requires a round trip to the browser, the browser requested the show action with +/books/1+ and the controller finds that there are no books, so the controller sends out a 302 redirect response to the browser telling it to go to +/books/+, the browser complies and sends a new request back to the controller asking now for the +index+ action, the controller then gets all the books in the database and renders the index template, sending it back down to the browser which then shows it on your screen. -While in a small app, this added latency might not be a problem, it is something to think about when speed of response is of the essence. One way to handle this double request (though a contrived example) could be: +While in a small app, this added latency might not be a problem, it is something to think about when speed of response is of the essence. One way to handle this double request (though a contrived example) could be: <ruby> def index @@ -695,13 +695,13 @@ To include +http://example.com/main.js+: <%= javascript_include_tag "http://example.com/main.js" %> </erb> -The +:defaults+ option loads jQuery by default: +If the application does not use the asset pipeline, the +:defaults+ option loads jQuery by default: <erb> <%= javascript_include_tag :defaults %> </erb> -If the application was generated with "-j prototype" <tt>:defaults</tt> loads Prototype and Scriptaculous. And you can in any case override the expansion in <tt>config/application.rb</tt>: +And you can in any case override the expansion in <tt>config/application.rb</tt>: <ruby> config.action_view.javascript_expansions[:defaults] = %w(foo.js bar.js) @@ -709,7 +709,7 @@ config.action_view.javascript_expansions[:defaults] = %w(foo.js bar.js) When using <tt>:defaults</tt>, if an <tt>application.js</tt> file exists in <tt>public/javascripts</tt> it will be included as well at then end. -The +:all+ option loads every JavaScript file in +public/javascripts+: +Also, the +:all+ option loads every JavaScript file in +public/javascripts+: <erb> <%= javascript_include_tag :all %> @@ -860,7 +860,7 @@ Produces <video src="/videos/movie.ogg" /> </erb> -Like an +image_tag+ you can supply a path, either absolute, or relative to the +public/videos+ directory. Additionally you can specify the +:size => "#{width}x#{height}"+ option just like an +image_tag+. Video tags can also have any of the HTML options specified at the end (+id+, +class+ et al). +Like an +image_tag+ you can supply a path, either absolute, or relative to the +public/videos+ directory. Additionally you can specify the +:size => "#{width}x#{height}"+ option just like an +image_tag+. Video tags can also have any of the HTML options specified at the end (+id+, +class+ et al). The video tag also supports all of the +<video>+ HTML options through the HTML options hash, including: @@ -1133,7 +1133,7 @@ You can also pass in arbitrary local variables to any partial you are rendering Would render a partial +_products.html.erb+ once for each instance of +product+ in the +@products+ instance variable passing the instance to the partial as a local variable called +item+ and to each partial, make the local variable +title+ available with the value +Products Page+. -TIP: Rails also makes a counter variable available within a partial called by the collection, named after the member of the collection followed by +_counter+. For example, if you're rendering +@products+, within the partial you can refer to +product_counter+ to tell you how many times the partial has been rendered. This does not work in conjunction with the +:as => :value+ option. +TIP: Rails also makes a counter variable available within a partial called by the collection, named after the member of the collection followed by +_counter+. For example, if you're rendering +@products+, within the partial you can refer to +product_counter+ to tell you how many times the partial has been rendered. This does not work in conjunction with the +:as => :value+ option. You can also specify a second partial to be rendered between instances of the main partial by using the +:spacer_template+ option: |