| 52 | | # Action Controllers are made up of one or more actions that performs its purpose and then either renders a template or |
|---|
| 53 | | # redirects to another action. An action is defined as a public method on the controller, which will automatically be |
|---|
| 54 | | # made accessible to the web-server through a mod_rewrite mapping. A sample controller could look like this: |
|---|
| | 52 | # Action Controllers are the core of a web request in Rails. They are made up of one or more actions that are executed |
|---|
| | 53 | # on request and then either render a template or redirect to another action. An action is defined as a public method |
|---|
| | 54 | # on the controller, which will automatically be made accessible to the web-server through Rails Routes. |
|---|
| | 55 | # |
|---|
| | 56 | # A sample controller could look like this: |
|---|
| 67 | | # GuestBookController.template_root = "templates/" |
|---|
| 68 | | # GuestBookController.process_cgi |
|---|
| 69 | | # |
|---|
| 70 | | # All actions assume that you want to render a template matching the name of the action at the end of the performance |
|---|
| 71 | | # unless you tell it otherwise. The index action complies with this assumption, so after populating the @entries instance |
|---|
| 72 | | # variable, the GuestBookController will render "templates/guestbook/index.rhtml". |
|---|
| 73 | | # |
|---|
| 74 | | # Unlike index, the sign action isn't interested in rendering a template. So after performing its main purpose (creating a |
|---|
| 75 | | # new entry in the guest book), it sheds the rendering assumption and initiates a redirect instead. This redirect works by |
|---|
| 76 | | # returning an external "302 Moved" HTTP response that takes the user to the index action. |
|---|
| | 69 | # Actions, by default, render a template in the <tt>app/views</tt> directory corresponding to the name of the controller and action |
|---|
| | 70 | # after executing code in the action. For example, the +index+ action of the +GuestBookController+ would render the |
|---|
| | 71 | # template <tt>app/views/guestbook/index.rhtml</tt> by default after populating the <tt>@entries</tt> instance variable. |
|---|
| | 72 | # |
|---|
| | 73 | # Unlike index, the sign action will not render a template. After performing its main purpose (creating a |
|---|
| | 74 | # new entry in the guest book), it initiates a redirect instead. This redirect works by returning an external |
|---|
| | 75 | # "302 Moved" HTTP response that takes the user to the index action. |
|---|
| 104 | | # All request parameters, whether they come from a GET or POST request, or from the URL, are available through the params hash. |
|---|
| 105 | | # So an action that was performed through /weblog/list?category=All&limit=5 will include { "category" => "All", "limit" => 5 } |
|---|
| 106 | | # |
|---|
| | 97 | # All request parameters, whether they come from a GET or POST request, or from the URL, are available through the params method |
|---|
| | 98 | # which returns a hash. For example, an action that was performed through <tt>/weblog/list?category=All&limit=5</tt> will include |
|---|
| | 99 | # <tt>{ "category" => "All", "limit" => 5 }</tt> in params. |
|---|
| | 128 | # By default, sessions are stored on the file system in <tt>RAILS_ROOT/tmp/sessions</tt>. Any object can be placed in the session |
|---|
| | 129 | # (as long as it can be Marshalled). But remember that 1000 active sessions each storing a 50kb object could lead to a 50MB store on the filesystem. |
|---|
| | 130 | # In other words, think carefully about size and caching before resorting to the use of the session on the filesystem. |
|---|
| | 131 | # |
|---|
| | 132 | # An alternative to storing sessions on disk is to use ActiveRecordStore to store sessions in your database, which can solve problems |
|---|
| | 133 | # caused by storing sessions in the file system and may speed up your application. To use ActiveRecordStore, uncomment the line: |
|---|
| | 134 | # |
|---|
| | 135 | # config.action_controller.session_store = :active_record_store |
|---|
| | 136 | # |
|---|
| | 137 | # in your <tt>environment.rb</tt> and run <tt>rake db:sessions:create</tt>. |
|---|
| | 138 | # |
|---|
| 174 | | # Redirecting is what actions that update the model do when they're done. The <tt>save_post</tt> method shouldn't be responsible for also |
|---|
| 175 | | # showing the post once it's saved -- that's the job for <tt>show_post</tt>. So once <tt>save_post</tt> has completed its business, it'll |
|---|
| 176 | | # redirect to <tt>show_post</tt>. All redirects are external, which means that when the user refreshes his browser, it's not going to save |
|---|
| 177 | | # the post again, but rather just show it one more time. |
|---|
| 178 | | # |
|---|
| 179 | | # This sounds fairly simple, but the redirection is complicated by the quest for a phenomenon known as "pretty urls". Instead of accepting |
|---|
| 180 | | # the dreadful being that is "weblog_controller?action=show&post_id=5", Action Controller goes out of its way to represent the former as |
|---|
| 181 | | # "/weblog/show/5". And this is even the simple case. As an example of a more advanced pretty url consider |
|---|
| 182 | | # "/library/books/ISBN/0743536703/show", which can be mapped to books_controller?action=show&type=ISBN&id=0743536703. |
|---|
| 183 | | # |
|---|
| 184 | | # Redirects work by rewriting the URL of the current action. So if the show action was called by "/library/books/ISBN/0743536703/show", |
|---|
| 185 | | # we can redirect to an edit action simply by doing <tt>redirect_to(:action => "edit")</tt>, which could throw the user to |
|---|
| 186 | | # "/library/books/ISBN/0743536703/edit". Naturally, you'll need to setup the routes configuration file to point to the proper controller |
|---|
| 187 | | # and action in the first place, but once you have, it can be rewritten with ease. |
|---|
| 188 | | # |
|---|
| 189 | | # Let's consider a bunch of examples on how to go from "/clients/37signals/basecamp/project/dash" to somewhere else: |
|---|
| 190 | | # |
|---|
| 191 | | # redirect_to(:action => "edit") => |
|---|
| 192 | | # /clients/37signals/basecamp/project/dash |
|---|
| 193 | | # |
|---|
| 194 | | # redirect_to(:client_name => "nextangle", :project_name => "rails") => |
|---|
| 195 | | # /clients/nextangle/rails/project/dash |
|---|
| 196 | | # |
|---|
| 197 | | # Those redirects happen under the configuration of: |
|---|
| 198 | | # |
|---|
| 199 | | # map.connect 'clients/:client_name/:project_name/:controller/:action' |
|---|
| | 174 | # Redirects are used to move from one action to another. For example, after a <tt>create</tt> action, which stores a blog entry to a database, |
|---|
| | 175 | # we might like to show the user the new entry. Because we're following good DRY principles (Don't Repeat Yourself), we're going to reuse (and redirect to) |
|---|
| | 176 | # a <tt>show</tt> action that we'll assume has already been created. The code might look like this: |
|---|
| | 177 | # |
|---|
| | 178 | # def create |
|---|
| | 179 | # @entry = Entry.new(params[:entry]) |
|---|
| | 180 | # if @entry.save |
|---|
| | 181 | # # The entry was saved correctly, redirect to show |
|---|
| | 182 | # redirect_to :action => 'show', :id => @entry.id |
|---|
| | 183 | # else |
|---|
| | 184 | # # things didn't go so well, do something else |
|---|
| | 185 | # end |
|---|
| | 186 | # end |
|---|
| | 187 | # |
|---|
| | 188 | # In this case, after saving our new entry to the database, the user is redirected to the <tt>show</tt> method which is then executed. |
|---|
