Rails - Feb 2008 - Strategy design pattern vs partial

I have a Rails application (something like an online catalog) that needs to
behave differently for different types of clients. For example, boat dealers
and car dealers.

- When the application displays a list of cars, it needs to list car
attributes, like horsepower and gas milage.
- When the application displays a list of boats, in needs to list boat
attributes, like LWL and sail area.

I would normally use the Strategy design pattern to implement these
different types of behavior.

But with Rails, it seems much more natural to implement the different views
of the data as partials, with the car-data view in one partial and the
boat-data view in another partial. The application can then include the boat
partial for boat dealers, and the car partial for car dealers. The
application can be extended for other types of dealers simply by adding a
new partial.

This solution separates out the stuff that changes (the view of the data)
from the stuff that doesn''t (the stuff that creates the list of
inventory
''items''), and keeps the car-view code separate from the
boat-view code.

Furthermore, using a partial doesn''t seem hugely different from using a
Proc
object, which was the first Strategy solution I thought of.

In other words, using partials seems a more Rails way of implementing a
Strategy-like solution, at least when viewing data. However, it''s not
very
OO, and I feel guilty using this easy ''cheat''.

Has anyone else run into this issue? Your thoughts much appreciated.

Brgds: John

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 15, 10:25 pm, Identry
<iden...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I have a Rails application (something like an online catalog) that needs to
> behave differently for different types of clients. For example, boat
dealers
> and car dealers.....
>
> I would normally use the Strategy design pattern to implement these
> different types of behavior.
>
> But with Rails, it seems much more natural to implement the different views
> of the data as partials, with the car-data view in one partial and the
> boat-data view in another partial....
>
> This solution separates out the stuff that changes (the view of the data)
> from the stuff that doesn''t (the stuff that creates the list of
inventory
> ''items''), and keeps the car-view code separate from the
boat-view code.
>
> Furthermore, using a partial doesn''t seem hugely different from
using a Proc
> object, which was the first Strategy solution I thought of.
>
> In other words, using partials seems a more Rails way of implementing a
> Strategy-like solution, at least when viewing data. However, it''s
not very
> OO, and I feel guilty using this easy ''cheat''.
Why?  Who are you cheating?  Sounds like somewhere along the line you
absorbed some OO dogma.  Most OO dogma is about going to extra trouble
today to save trouble tomorrow.  Forget about it.  Save tomorrow for
tomorrow, think about today instead.  Just write the code in the
simplest possible way.  If becomes awkward later, change it.  Your
functional tests will validate the change.
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Agreed!

I am assuming that somewhere along the line you have some way of
determining the dealer type (STI?).  Why wouldn''t it be
''OO'' to do
something like:

render :partial=>"show_#{dealer_type.underscore}"

On Feb 16, 2:42 am, kevin  cline
<kevin.cl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Feb 15, 10:25 pm, Identry
<iden...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> > I have a Rails application (something like an online catalog) that
needs to
> > behave differently for different types of clients. For example, boat
dealers
> > and car dealers.....
>
> > I would normally use the Strategy design pattern to implement these
> > different types of behavior.
>
> > But with Rails, it seems much more natural to implement the different
views
> > of the data as partials, with the car-data view in one partial and the
> > boat-data view in another partial....
>
> > This solution separates out the stuff that changes (the view of the
data)
> > from the stuff that doesn''t (the stuff that creates the list
of inventory
> > ''items''), and keeps the car-view code separate from
the boat-view code.
>
> > Furthermore, using a partial doesn''t seem hugely different
from using a Proc
> > object, which was the first Strategy solution I thought of.
>
> > In other words, using partials seems a more Rails way of implementing
a
> > Strategy-like solution, at least when viewing data. However,
it''s not very
> > OO, and I feel guilty using this easy ''cheat''.
>
> Why?  Who are you cheating?  Sounds like somewhere along the line you
> absorbed some OO dogma.  Most OO dogma is about going to extra trouble
> today to save trouble tomorrow.  Forget about it.  Save tomorrow for
> tomorrow, think about today instead.  Just write the code in the
> simplest possible way.  If becomes awkward later, change it.  Your
> functional tests will validate the change.
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Well the OO-Rails-Way to solve this is to have a model for Cars and
one for Boots. These Models would typically inherit from some vehicle-
class if u have common attributes and functions.
You can then display Boots and Cars in their Views and not in some
other View where they don''t belong. Just redirect to the appropriate
view for the your dealer
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I don''t think there''s any confusion about the different models
to use,
the question is the best wasy to "display Boats and Cars in their
Views..."  Strategy Pattern answers that problem by giving a mechanism
to perform that view selection.

On Feb 16, 3:25 pm, "sohra...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org"
<sohra...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
> Well the OO-Rails-Way to solve this is to have a model for Cars and
> one for Boots. These Models would typically inherit from some vehicle-
> class if u have common attributes and functions.
> You can then display Boots and Cars in their Views and not in some
> other View where they don''t belong. Just redirect to the
appropriate
> view for the your dealer
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

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.

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



On Feb 18, 4:49 pm, Identry
<iden...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---