For a given widget, there are two ways to display it: full and
summary. These are handled by partials: widget_full and
widget_summary. Both partials depend heavily on methods in the
helper. But they fight over method names.
For instance, both partials want to call "text_html". I
don''t want to
have heaps of methods in the helper, like "text_summary_html" and
"text_full_html". But each view only has one helper, so the partials
will have to just get along.
I tried to partition the helper namespace by introducing classes:
module WidgetHelper
class SummaryViewHelper
def initialize(widget)
@w = widget
end
def text_html # WidgetHelper::SummaryViewHelper#text_html
# summary view of the text
end
end
class FullViewHelper
def initialize(widget)
@w = widget
end
def text_html # WidgetHelper::FullViewHelper#text_html
# full view of the text
end
end
end
So far so good. Now the partials look like this:
_widget_full.rhtml:
<% h = FullViewHelper.new(widget) %>
...
Text: <%= h.text_html %>
_widget_summary.rhtml:
<% h = SummaryViewHelper.new(widget) %>
...
Text: <%= h.text_html %>
I quite like that arrangement. (Of course, there are many more
methods, and the partials are very different, so the a priory
complexity of it is more justified that it appears above.)
However, there''s a problem.
module WidgetHelper
class SummaryViewHelper
def foo
link_to :action => :foo # THIS DOESN''T WORK
end
end
end
I can''t call link_to from that method because the class WidgetHelper
doesn''t have ActionView::Helpers::UrlHelper in it. OK, so I include
it manually. But it _still_ doesn''t work, because the implementation
of link_to depends on the instance variable @controller. The magic in
Rails makes that available to the module WidgetHelper, but it doesn''t
extend to classes defined within that module.
So I''m going to have to do something else to manage the complexity in
the helper. I don''t expect anyone to have a solution to the problem
above, but I''d appreciate general comments. How do you deal with
complexity in helpers?
Cheers,
Gavin
Hey Gavin, I found myself in the exact same scenario this weekend. I ended demoting my classes to modules (because they only really had one method that mattered). It certainly doesn''t feel right, but it solves my immediate problem. I''d love to have an implementation for classes though. Maybe a "best practices" for helpers discussion is needed?? Maybe a "helper_helper" command to arm our classes with the current helpers. Ok, now I''m just confusing myself. Steve On Apr 10, 2005 3:14 AM, Gavin Sinclair <gsinclair-81uBx+iSpXA0n/F98K4Iww@public.gmane.org> wrote:> For a given widget, there are two ways to display it: full and > summary. These are handled by partials: widget_full and > widget_summary. Both partials depend heavily on methods in the > helper. But they fight over method names. > > For instance, both partials want to call "text_html". I don''t want to > have heaps of methods in the helper, like "text_summary_html" and > "text_full_html". But each view only has one helper, so the partials > will have to just get along. > > I tried to partition the helper namespace by introducing classes: > > module WidgetHelper > > class SummaryViewHelper > def initialize(widget) > @w = widget > end > > def text_html # WidgetHelper::SummaryViewHelper#text_html > # summary view of the text > end > end > > class FullViewHelper > def initialize(widget) > @w = widget > end > > def text_html # WidgetHelper::FullViewHelper#text_html > # full view of the text > end > end > > end > > So far so good. Now the partials look like this: > > _widget_full.rhtml: > <% h = FullViewHelper.new(widget) %> > ... > Text: <%= h.text_html %> > > _widget_summary.rhtml: > <% h = SummaryViewHelper.new(widget) %> > ... > Text: <%= h.text_html %> > > I quite like that arrangement. (Of course, there are many more > methods, and the partials are very different, so the a priory > complexity of it is more justified that it appears above.) > > However, there''s a problem. > > module WidgetHelper > class SummaryViewHelper > def foo > link_to :action => :foo # THIS DOESN''T WORK > end > end > end > > I can''t call link_to from that method because the class WidgetHelper > doesn''t have ActionView::Helpers::UrlHelper in it. OK, so I include > it manually. But it _still_ doesn''t work, because the implementation > of link_to depends on the instance variable @controller. The magic in > Rails makes that available to the module WidgetHelper, but it doesn''t > extend to classes defined within that module. > > So I''m going to have to do something else to manage the complexity in > the helper. I don''t expect anyone to have a solution to the problem > above, but I''d appreciate general comments. How do you deal with > complexity in helpers? > > Cheers, > Gavin > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hi, Maybe you could try something like this (untested, I don''t know if this works!): ::link_to :action => :foo or WidgetHelper::link_to Hope it helps. Kind Regards, Flurin Egger Gavin Sinclair wrote:>For a given widget, there are two ways to display it: full and >summary. These are handled by partials: widget_full and >widget_summary. Both partials depend heavily on methods in the >helper. But they fight over method names. > >For instance, both partials want to call "text_html". I don''t want to >have heaps of methods in the helper, like "text_summary_html" and >"text_full_html". But each view only has one helper, so the partials >will have to just get along. > >I tried to partition the helper namespace by introducing classes: > > module WidgetHelper > > class SummaryViewHelper > def initialize(widget) > @w = widget > end > > def text_html # WidgetHelper::SummaryViewHelper#text_html > # summary view of the text > end > end > > class FullViewHelper > def initialize(widget) > @w = widget > end > > def text_html # WidgetHelper::FullViewHelper#text_html > # full view of the text > end > end > > end > >So far so good. Now the partials look like this: > > _widget_full.rhtml: > <% h = FullViewHelper.new(widget) %> > ... > Text: <%= h.text_html %> > > _widget_summary.rhtml: > <% h = SummaryViewHelper.new(widget) %> > ... > Text: <%= h.text_html %> > >I quite like that arrangement. (Of course, there are many more >methods, and the partials are very different, so the a priory >complexity of it is more justified that it appears above.) > >However, there''s a problem. > > module WidgetHelper > class SummaryViewHelper > def foo > link_to :action => :foo # THIS DOESN''T WORK > end > end > end > >I can''t call link_to from that method because the class WidgetHelper >doesn''t have ActionView::Helpers::UrlHelper in it. OK, so I include >it manually. But it _still_ doesn''t work, because the implementation >of link_to depends on the instance variable @controller. The magic in >Rails makes that available to the module WidgetHelper, but it doesn''t >extend to classes defined within that module. > >So I''m going to have to do something else to manage the complexity in >the helper. I don''t expect anyone to have a solution to the problem >above, but I''d appreciate general comments. How do you deal with >complexity in helpers? > >Cheers, >Gavin > >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > >
> So I''m going to have to do something else to manage the complexity in > the helper. I don''t expect anyone to have a solution to the problem > above, but I''d appreciate general comments. How do you deal with > complexity in helpers?You can create multiple helpers of your own that doesn''t have a 1-1 mapping to the controllers. So you could have ExtraWidgetHelper and include that in a given controller with helper :extra_widget_helper -- but you still have a flat namespace. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
On Monday, April 11, 2005, 9:07:16 PM, David wrote:>> So I''m going to have to do something else to manage the complexity in >> the helper. I don''t expect anyone to have a solution to the problem >> above, but I''d appreciate general comments. How do you deal with >> complexity in helpers?> You can create multiple helpers of your own that doesn''t have a 1-1 > mapping to the controllers. So you could have ExtraWidgetHelper and > include that in a given controller with helper :extra_widget_helper -- > but you still have a flat namespace.I didn''t know that. Thanks for pointing it out! Do you think it''s desirable to add some support for segmenting the namespace in a helper? Not urgent, of course, but in some future Rails? Cheers, Gavin
> Do you think it''s desirable to add some support for segmenting the > namespace in a helper? Not urgent, of course, but in some future > Rails?Possibly. I don''t think its a big deal for most systems, though. Prefixing a helper method with x_helper and y_helper instead of X::HelperClass or Y::HelperClass seems to be a simpler solution for the majority of the cases. And if you truly do need namespacing, perhaps the helpers are doing too much. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
On Tuesday, April 12, 2005, 1:12:17 AM, David wrote:>> Do you think it''s desirable to add some support for segmenting the >> namespace in a helper? Not urgent, of course, but in some future >> Rails?> And if you truly do need namespacing, perhaps the helpers are doing too > much.Yeah, probably... Gavin