dry collections in other models

rubyonrails-talk
#1

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

#2

Hi Craig,

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

http://railscasts.com/episodes/88-dynamic-select-menus

Have fun,
Franz

#3

Hi Craig,

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

http://railscasts.com/episodes/88-dynamic-select-menus

#4

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 Jones

#5

> 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...