More Rails

Class names are mixed case (each word
starts with a capital letter, and there are no breaks). Table names (and, as
we’ll see later, variable names and symbols) are lowercase, with an underscore
between words

Over in app/controllers you’ll find a file called application.
rb. This file is used to establish a context for the entire application.
By default, it contains an empty definition of class ApplicationController.

If we end a piece of
embedded Ruby with -%> (note the extra minus sign), ERb will suppress the
newline that follows. That means embedded Ruby that doesn’t generate
any output won’t end up leaving extraneous blank lines in the output.

A commonly used method of array objects is <<, which appends a value to
its receiver.

The session construct stores the objects that you want to keep around
between browser requests. To make this work, Rails has to take these
objects and store them at the end of one request, loading them back
in when a subsequent request comes in from the same browser. To
store objects outside the running application, Rails uses Ruby’s serialization
mechanism, which converts objects to data that can be loaded back in.

Rails has a convenient way of dealing with
errors and error reporting. It defines a structure called a flash. A flash is a
bucket (actually closer to a Hash), into which you can store stuff as you process
a request. The contents of the flash are available to the next request
in this session before being deleted automatically. Typically the flash is
used to collect error messages

The flash information is accessible within the views by using the @flash instance variable.

Why couldn’t we just store the error in any old instance variable? Remember
that a redirect is sent by our application to the browser, which then
sends a new request back to our application. By the time we receive that
request, our application has moved on—all the instance variables from
previous requests are long gone. The flash data is stored in the session in
order to make it available between requests.

A helper is simply code in a module that is automatically included into your views.
You define helper files in app/helpers. A helper named xyz_helper.rb defines
methods that will be available to views invoked by the xyz controller. If
you define helper methods in the file app/helpers/application_helper.rb, those
methods will be available in all views.

model objects perform two roles: they map data into and out of the
database, but they are also just regular objects that hold business data.
They affect the database only when you tell them to, typically by calling
save( ).

The render_component( ) method invokes the given action and substitutes
the output it renders into the current view.


one way of handling subroutines at the view level is by using components to show the contents of a page on some other page. A lighter-weight way of doing the same thing is using a partial template. Unlike the component-based approach, a partial template
has no corresponding action; it’s simply a chunk of template code
that has been factored into a separate file

We know how to create new rows in a database table; we create an action,
put a form into a view, and invoke the model to save data away.

Inside a Rails controller, the request information is available in the attribute request. We can check the request type using the methods get?( ) and post?( ).

form_tag needs no parameters, as it defaults to submitting the form back
to the action and controller that rendered the template

Ruby’s attr_accessor creates a read/write attribute in the model.