22 lines
1.2 KiB
Text
22 lines
1.2 KiB
Text
|
Action Pack splits the response to a web request into a controller
|
||
|
|
part (performing the logic) and a view part (rendering a template).
|
||
|
|
This two-step approach is known as an action, which will normally
|
||
|
|
create, read, update, or delete (CRUD for short) some sort of model
|
||
|
|
part (often backed by a database) before choosing either to render a
|
||
|
|
template or redirecting to another action.
|
||
|
|
|
||
|
|
Action Pack implements these actions as public methods on Action
|
||
|
|
Controllers and uses Action Views to implement the template rendering.
|
||
|
|
Action Controllers are then responsible for handling all the actions
|
||
|
|
relating to a certain part of an application. This grouping usually
|
||
|
|
consists of actions for lists and for CRUDs revolving around a single
|
||
|
|
(or a few) model objects. So ContactController would be responsible
|
||
|
|
for listing contacts, creating, deleting, and updating contacts. A
|
||
|
|
WeblogController could be responsible for both posts and comments.
|
||
|
|
|
||
|
|
Action View templates are written using embedded Ruby in tags mingled
|
||
|
|
in with the HTML. To avoid cluttering the templates with code, a
|
||
|
|
bunch of helper classes provide common behavior for forms, dates, and
|
||
|
|
strings. And it's easy to add specific helpers to keep the separation
|
||
|
|
as the application evolves.
|