Dry collections in other models

Starting over, mail program sent prematurely…

2 models, Salons, Reviews

In ApplicationHelper.rb…

SALON_STATES = Salon.find(:all, :group => ‘state’, :select => ‘state’)

So in any view, I can collect…

<%= options = [[ ‘Select a State’, @state ]] +
ApplicationHelper::SALON_STATES.collect { |salon| [salon.state] }
select ‘salon’, ‘state’, options %>

This is OK (perhaps maybe not the best way to handle and I’m open to
suggestions)

But now, I want a list of cities in just the selected state and I can’t
manage to accomplish this anywhere but in controller code which is not
very dry since I would have to replicate this code in several different
controllers (like Reviews).

@cities = Salon.find(:all, :conditions => [‘active = true AND state
= ?’, @state], :group => ‘city’, :select => ‘city’)

Suggestions?

Craig


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Hi Craig,

I had to do something similar to this in one of my apps. Ryan B.
did an excellent tutorial you may want to consider.

Have fun,
Franz

On Sun, 2010-02-07 at 14:12 +0100, Franz S. wrote:

Hi Craig,

I had to do something similar to this in one of my apps. Ryan B.
did an excellent tutorial you may want to consider.

#88 Dynamic Select Menus - RailsCasts


I may ultimately go down that road but I am playing with named_scope
since it’s really something I should be mastering anyway and so I will
ask about that in another thread…

Thanks

Craig


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

On Feb 6, 6:57 am, Craig W. [email protected] wrote:

Starting over, mail program sent prematurely…

2 models, Salons, Reviews

In ApplicationHelper.rb…

SALON_STATES = Salon.find(:all, :group => ‘state’, :select => ‘state’)

Unrelated to your original question, but DON’T DO THIS. It works (for
suitably small values of “works”) in development mode, but will cause
odd behavior when deployed to production. At a minimum, Salons which
are added after the application starts won’t show up until the server
restarts. In a dynamic environment like Passenger, you could even end
up with different processes having different lists in
SALON_STATES…

–Matt J.

On Sun, 2010-02-07 at 15:11 -0800, Matt J. wrote:

Unrelated to your original question, but DON’T DO THIS. It works (for
suitably small values of “works”) in development mode, but will cause
odd behavior when deployed to production. At a minimum, Salons which
are added after the application starts won’t show up until the server
restarts. In a dynamic environment like Passenger, you could even end
up with different processes having different lists in
SALON_STATES…


yeah thanks

I’ve already moved this code into the ‘Salons’ model as a named_scope

:wink:

Craig


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.