On 27/02/2005, at 10:53 AM, Adam Fields wrote:> I''m looking through a number of tutorials, and it looks like
they''ve
> all got a fair amount of logic encoded in the controller files.
>
> For example, here:
> http://manuals.rubyonrails.com/read/chapter/38#page109
>
> a new action "add_item" is defined, and all of the code to do the
save
> and error handling is right there in the add_item method in the
> controller. The subsequent actions/methods added in the same chapter
> seem to do this too.
>
> Is this the "right" place for such code, or is that just an
example
> for convenience?
The "right place" for any code depends on your specific application.
You could place the logic into your model, but then you don''t want your
model to depend on ActionPack do you?
How could we abstract the add_item, and what advantages would this have?
If we have a separate facade module, we could change add_item from:
def add_item
item = Todo.new(@params["new_item"]) # Create a new instance with
the
fields of item being set to what''s in the "new_item" hash
if item.save # Try to save our item into the database
redirect_to(:action => "list") # Return to the list page if
it
suceeds
else
render_text "Couldn''t add new item" # Print an error
message
otherwise
end
end
to:
def add_item
item = Todo.new(@params["new_item"]) # Create a new instance with
the
fields of item being set to what''s in the "new_item" hash
if facade.save # Try to save our item into the database using the
facade
redirect_to(:action => "list") # Return to the list page if
it
suceeds
else
render_text "Couldn''t add new item" # Print an error
message
otherwise
end
end
Nope... can''t really see the advantage there...
> I guess what I''m looking for is a Facade, or something like it.
But why?
You could package the code into a standard ruby module (without
actionpack dependencies) and call that from your controller, or maybe a
Rails 0.10 module (with actionpack dependencies).
But again, is the abstraction neccessary?
- tim lucas