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
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
The helpers could then be responsible for injecting the appropriate
3. 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.
self.class.include( --pick your strategy module-- )
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.