Forum: Ruby on Rails DRYing/shortening form processing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick (Guest)
on 2008-10-24 17:53
(Received via mailing list)
So I have this form with >10 fields on it. When the form is submitted,
the corresponding controller action calls the class method
#filtered_properties to process the data.

I've created separate class methods for processing each parameter,
which #filtered_properties
calls. However, #filtered_properties is still 120 lines long. This is
because each "section" that processes a param is 10 lines long. Each
of these "sections" is different in one or two ways, but they're all
extremely similar.

Might you have any suggestions for how to make #filtered_properties
more DRY and/or shorter?:
http://pastie.org/299720

Thanks, guys!
Nick
A91bd6cef23eb3516245a092e196c4da?d=identicon&s=25 Maurício Linhares (mauricio)
on 2008-10-24 19:03
(Received via mailing list)
Hi Nick,

I can't imagine a reason why these methods are class and not instance
methods, could you please explain a litle bit more about your idea,
your model and your controller and what do you really want with these
filter_property methods?

On Fri, Oct 24, 2008 at 12:52 PM, Nick <nick@deadorange.com> wrote:
> extremely similar.
>
> Might you have any suggestions for how to make #filtered_properties
> more DRY and/or shorter?:
> http://pastie.org/299720
>
> Thanks, guys!
> Nick
> >
>



--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/
(en)
João Pessoa, PB, +55 83 8867-7208
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick (Guest)
on 2008-10-24 21:18
(Received via mailing list)
On Oct 24, 1:02 pm, "Maurício Linhares" <mauricio.linha...@gmail.com>
wrote:
> Hi Nick,
>
> I can't imagine a reason why these methods are class and not instance
> methods, could you please explain a litle bit more about your idea,
> your model and your controller and what do you really want with these
> filter_property methods?


Hi Maurício. They're class methods because they don't rely upon an
instance of the Property model. They're for finding properties that
match the search criteria submitted by the user.

Here's how it works:
1) A user browses to /neighbourhoods/1/map/ . A Google Map is
displayed, and properties within that neighbourhood are plotted on the
map.
2) There's a form that allows the user to filter which properties are
plotted on the map. For example, they can filter based on the:
      -number of bedrooms;
      -number of bathrooms;
      -min or max price;
      -etc.
3) When the user submits the form, the "map_filter" neighbourhood
action is called, which uses Property#filtered_properties to determine
which properties match the user's search criteria.
4) Property#filtered_properties calls the #filtered_X class method
that corresponds to each form field value. When #filtered_properties
finishes processing each form field value, it checks to see if an
error occured, and returns an appropriate value (IE: either the error
messages, or the properties that match the search criteria).

I hope that explains things a bit more clearly. Cheers,
Nick
A91bd6cef23eb3516245a092e196c4da?d=identicon&s=25 Maurício Linhares (mauricio)
on 2008-10-24 21:37
(Received via mailing list)
Well, instead of doing it using class methods , you could do it using
this ->
http://github.com/staugaard/active_record_base_wit...

You get all active record validations, active record error handling
and instead of doing it in an ugly class method that looks like a
"function" you can have your Property instance to generate the SQL
code you're generating now in the class methods.

On Fri, Oct 24, 2008 at 4:18 PM, Nick <nick@deadorange.com> wrote:
>
>      -number of bedrooms;
> messages, or the properties that match the search criteria).
>
> I hope that explains things a bit more clearly. Cheers,
> Nick
> >
>



--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/
(en)
João Pessoa, PB, +55 83 8867-7208
A91bd6cef23eb3516245a092e196c4da?d=identicon&s=25 Maurício Linhares (mauricio)
on 2008-10-24 21:54
(Received via mailing list)
Here's an idea of what i'm talking about => http://pastie.org/299940

On Fri, Oct 24, 2008 at 4:18 PM, Nick <nick@deadorange.com> wrote:
>
>      -number of bedrooms;
> messages, or the properties that match the search criteria).
>
> I hope that explains things a bit more clearly. Cheers,
> Nick
> >
>



--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/
(en)
João Pessoa, PB, +55 83 8867-7208
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick (Guest)
on 2008-10-24 21:54
(Received via mailing list)
On Oct 24, 3:37 pm, "Maurício Linhares" <mauricio.linha...@gmail.com>
wrote:
> Well, instead of doing it using class methods , you could do it using
> this ->http://github.com/staugaard/active_record_base_wit...
>
> You get all active record validations, active record error handling
> and instead of doing it in an ugly class method that looks like a
> "function" you can have your Property instance to generate the SQL
> code you're generating now in the class methods.

Wow, that's a really useful plugin! Thanks for the link, mate. I'm
going to take a serious look at it.
-Nick
This topic is locked and can not be replied to.