On 09/02/10 01:32, Marnen Laibow-Koser wrote:
Andrew France wrote:
Hi,
I was thinking whether it would be more elegant for a view to call
methods on the controller rather than rely on instance variables.
The trouble with this is that controller methods are actions, not
getters.
It's quite common for controllers to have methods which are not directly
actions. By default they are accessible from URLs but it's good practice
to remove the default route anyway. Plus they could be set to protected
(workaround probably required) or hidden with hide_action.
I'm
not really sure what the answer is so thought I would throw it out
here.
Perhaps with a basic DSL that makes it explicit what the controller is
setting, like:
class BooksController< ActionController::Base
var :book do
Book.find(params[:id])
end
end
where var:
class ApplicationController..
def self.var(name,&block)
define_method(name, block)
helper_method(name)
# Perhaps memoize too?
end
end
Does this violate the rule that the controller should be driving the
view?
Yes. The controller just passes variables to the view.
Any major disadvantages you can see?
Lots. Does the view even have the controller object in scope? Should
it need to? What if you want to use the same partial with different
controllers?
The code above already works, if that answers your question.
As for using partials, well one of reasons for using methods is that
you're making the contract between the view and the controller more
explicit. You already have it with instance variables but I suppose
using unset instance vars to determine logic in views is a little easier
albeit less elegant.
Regards,
Andrew
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
