Routes - Search url parser

rubyonrails-talk
#1

Hello, I'm trying to set my routes.rb. I have Car that belongs to
Color and Brand. I want to build a clear url searcher without visible
variables. It's working for me this:

resources :Cars
match 'color/:color' => 'cars#index'
match 'brand/:brand' => 'cars#index'
match 'brand/:brand/color/:color' => 'cars#index'

But I think I could do the 3 "match" in only one line. Also, posibly
there is other alternatives for do it. All advices are welcome.
Thanks!

#2

For give a example, the url I hope to have is something like that:
- example.com/brand/ford/color/red
- example.com/brand/ford
- example.com/color/red

The idea is to have the same that:
- example.com/cars?brand=ford&color=red

But really, the user already knows that Ford is a brand and Red is a
color. I would prefer to have a url like that:
- example.com/ford/red

In this case I would have to parse the string in the controller. I
think would be okey this match:
- match '*search' => 'cars#index'

Some advice? Thanks.

#3

Any help?

#4

danimashu wrote in post #997411:

I would prefer to have a url like that:
- example.com/ford/red

But then what happens with:

- example.com/pink/cadillac ?

I'd be careful of investing any particular logic behind your urls for
dealing with arguments. Do all your users catagorize things the same
way you do? Probably not.

One person I work with definitely does not prioritize attributes in the
order I do, and she is invaluable because of it.

#5

Thanks for the answer.

But then what happens with:

- example.com/pink/cadillac ?

In the controller would have to check that pink is a Color and
cadillac is a Brand. Problem if some day there is a Brand with name of
Color. I don't know if it's worth wasting time on it. The classic way
sould be the correct then:
- example.com/cars?color=pink&brand=cadillac

If you have other ideas for do it you will be welcome. Bye

Daniel

#6

I would advise against a strategy that could ever be ambiguous, even
if it looks unlikely at the moment. It would likely bite you at some
point in the future, or even worse the developer who comes hereafter,
can you imagine what he/she would say about you when he realised the
problem and that he would have to do some major reworking? :slight_smile:

Colin

#7

I would advise against a strategy that could ever be ambiguous, even
if it looks unlikely at the moment. It would likely bite you at some
point in the future, or even worse the developer who comes hereafter,
can you imagine what he/she would say about you when he realised the
problem and that he would have to do some major reworking? :slight_smile:

Colin

Thanks for the advice! For the moment I will use classic way.