# Re: Strategy design pattern vs partial

**URL:** <https://www.ruby-forum.com/t/re-strategy-design-pattern-vs-partial/129476>\
**Category:** Rails\
**Created:** [February 18, 2008, 10:50pm UTC](https://www.ruby-forum.com/t/re-strategy-design-pattern-vs-partial/129476 "2008-02-18T22:50:09Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [February 18, 2008, 10:50pm UTC](https://www.ruby-forum.com/t/re-strategy-design-pattern-vs-partial/129476/1 "2008-02-18T22:50:09Z")

</div>

Andy,

I think you understand my question. The answers range in complexity from  
using partials, as you suggest (that’s what I’m doing now), to using an  
Abstract Factory to choose the correct Strategy in the various places in  
the  
application it’s needed.

The Abstract Factory would be the ideal solution, since it would  
centralize  
all the various views, rather than scattering them in various view  
directories.

However, at this stage, there are actually only a few partials for each  
type  
of dealer. So after due consideration, I think the partial approach,  
plus a  
few notes that will remind me what partials need to be created for each  
dealer, will do for now. If it gets too hairy to manage this way in the  
future, I can always refactor.

Thanks for confirming that I’m on the right track.

Brgds: John

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [February 20, 2008, 12:41am UTC](https://www.ruby-forum.com/t/re-strategy-design-pattern-vs-partial/129476/2 "2008-02-20T00:41:51Z")

</div>

John,

I didn’t meant to be dismissive at first. Really, my original post  
_was_ a strategy of sorts, just one that relied on the class of the  
dealer. It’s more interesting than that so I’ve not been able to get  
it out of my mind this afternoon. I can think of three ways you might  
handle this:

1. Namespacing.  
In Rails 2.x you can use the new map.namespace … method to namespace  
your paths. By doing that you could have a dealer\_car\_path, etc.  
What I believe you could do is namespace those controllers that need  
their own views while leaving the generic ones in the ‘default’  
namespace. The namespaced controllers could then be restricted to use  
controllers in their namespace and the default namespace. In a sense,  
the namespacing provides your strategy and you only have to pick the  
correct namespace on the dealer’s landing page. As a bonus, all the  
namespaced views/controllers would end up in a common subfolder (ie.,  
everything in the ‘car’ namespace in the app/views/cars/xxx folders).

2. View helpers  
It seems that the natural way to introduce the strategy methods would  
be by mixing in a module. Views already have modules mixed in…  
that’s what the helpers are all about. What I believe you could do  
here is render a default view (show.html.erb) and allow that view to  
invoke a helper method. The key would be to only include the  
appropriate helper method. What I’d suggest would be to keep these  
helpers in that were related to the controller name but not directly  
named after it. A ListingsController, for example, might get  
auto\_listing\_helper.rb and boat\_listing\_helper.rb. You’d use a before  
filter that would include a call like

helper “#{strategey}\_listing”

The helpers could then be responsible for injecting the appropriate  
partials.

1. Controller helpers  
This is a variant on 2. This time you’d write modules that  
encapsulated the strategy for dealing with a particular type of dealer  
for each controller. Then you would use a before filter to inject the  
controller methods into the controller.

def choose\_strategy  
self.class.include( --pick your strategy module-- )  
end

It’s possible that the action may need to be part of the controller  
before the before\_filter fires, so you might need to have the show  
method (e.g.,) delegate it’s response to the mixed-in functionality  
rather than implementing it fully in the module. The main advantage  
that you’d gain here would be the ability to do different data lookups  
if necessary. You’d also have a fairly clean way of deciding what  
partials to include in your view since you could pass that to the view  
through instance variables.

HTH,  
AndyV