Michael,
Tell me if I'm wrong, but how I understand it is that you'd like to
do the following:
1. Provide an Advanced Search form;
2. Keep the various fields within that form together to have
pagination-like functionality (i.e. keep the search information
around for pagination etc.);
Now, there are a number of ways to go about this and they all have to
do with maintaining the state of your search parameters for multiple
requests. An important question to ask is: "How long do I want the
search parameters to stick around?" Here are the two scenarios:
"I want the search parameters to stick around only for the initial
search query and subsequent page changes of that search query." The
solution for this scenario could be as follows:
1. Within your Search controller, create an array called
ADVANCED_PARAM_NAMES and fill it with the CGI parameter names you
would like to keep in tact for pagination and such;
Example:
ADVANCED_PARAM_NAMES = ["query", "results_per_page", "all_words",
"exact_phrase", ...]
2. If you haven't done so, create your Advanced Search form (making
sure to use the same parameter names from step 1);
3. To keep the values from the search around, you're going to need to
build a query string for the names and values from step one;
Example:
Write a helper method to serialize your parameters:
def serialize_params(keys, extras = {})
query_string = keys.collect do |key|
value = CGI.escape(params[key])
"#{key}=#{value}"
end
extras.each_pair do |key,value|
value = CGI.escape(value)
query_string << "#{key}=#{value}"
end
query_string.join('&')
end
4. Wherever you need these parameters, say on a link, simply do the
following:
<%= link_to "Next page", serialize_params
(ADVANCED_SEARCH_PARAMS, :page => 2) %>
The other scenario is, "I'd like these search parameters to stick
around for an arbitrary amount of time." This solution is even
simpler (use your session):
Take steps 1 and 2 from above.
3. Instead of writing your serialize_params method in a helper, write
it as a protected method inside of your search controller.
Example:
def serialize_params(keys, extras = {})
keys.each do |key|
(session[:advanced_search] ||= {})[key] = CGI.escape(params[key])
end
...
end
4. These parameters will stick around as long as you'd like or until
the user changes some parameter in the Advanced Search form.
Remember, to access these values is as simple as calling session
[:advanced_search][key_name], say for your form.
Example:
<%= text_field_tag :query, session[:advanced_search][:query]
I hope this helps. There should be enough here to get started.
-Jordan
On Feb 8, 2007, at 7:34 PM, Michael Frederick wrote:
Thanks for the response, Jordan. At least I have the feeling that
there are no simple answers to my questions.
I have no real problem with building my own specific database calls.
It's just that I was trying to stay 100% Rails normal throughout the
app, since it's my first serious Rails effort. And the API provides
about 95% of what I need, so this inconsistency between the existing
paradigms seems strange. Especially for a 1.2+ release.
The Searchable plugin idea is pretty interesting. I would envision
something like that as a sort of wrapper for the standard relationship
methods, so you could specify which relationship entities would be
search forms.
But right now, I would love a good quick fix. I'm hoping that before
the app goes live that the Rails devs will fix this, or that I will
fix it myself with a patch if I can't wait any longer. I think I can
make a simple helper script that wraps around url_for and generates
some additional params.
I'm still open to any other suggestions, of course.
- Michael
Date: Wed, 7 Feb 2007 11:57:11 -0800
From: "Jordan A. Fowler" <[EMAIL PROTECTED]>
Subject: Re: Re: Rails questions and problems
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Michael,
I've been thinking about your original post quite a bit. I think it
would be best to have a "search" controller, which you probably
already have that intercepts any search related parameters. For
instance, you could have a basic search action as well as an advanced
search action. For both of these actions, you'll probably want to
consolidate any database interactions into a single protected method
where you then query the specific models you're trying to search
against.
Don't always think you have to stick to the "Rails way" 100%. A lot
of times, you're going to need to fall back on your best instincts
and just solve the problem. If you wanted to get really fancy, you
could write a class or plugin that you mix-in to the models you want
searchable. I'd be interested in helping you out with this further.
Let me know if this helps...
-Jordan
On Feb 7, 2007, at 11:48 AM, Michael Frederick wrote:
> Thanks for the feedback, Tom. Let me try again from a higher level.
>
> I want to make an advanced search page. Now, all the search
parameters
> I'm interested in are not simply attributes of a single model. They
> may be attributes that come through many different relationships.
>
> I'm trying to use form_helpers, but they generate
inconsistencies and
> bugs when combined with url_for. So, any other ideas?
>
> - Michael
>
>
>> Date: Mon, 05 Feb 2007 11:46:08 -0800
>> From: Tom Werner <[EMAIL PROTECTED]>
>> Subject: Re: [Sdruby] Re: Rails questions and problems
>> To: [email protected]
>> Message-ID: <[EMAIL PROTECTED]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> I think it's a problem of not understanding what you're trying to
>> accomplish. Can you explain your interface and requirements at a
>> higher
>> level. There's probably an elegant Rails solution but we need
to know
>> exactly how you want it to behave.
>>
>> Tom
>>
>> Michael Frederick wrote:
>> > Sorry for the bump, but I think some of the excitement over
>> railsconf
>> > may have overshadowed my questions. :-)
>> >
>> > On 2/1/07, Michael Frederick <[EMAIL PROTECTED]> wrote:
>> >> I've been having some problems with designing an advanced
>> search page,
>> >> and how to integrate the functionality with normal Rails
>> paradigms.
>> >>
>> >> The basic approach has been to make a search object, and I have
>> done
>> >> this (for now) by using a Struct. This way, I can use the
>> >> form_helpers, and they will receive the default value of the
>> search
>> >> param corresponding to each field. Should I try and make this a
>> model
>> >> instead? Or some other type of class that will integrate well?
>> >>
>> >> So, I use form_helpers, and then I want to be able to allow
>> further
>> >> refining and reordering of the search using links. It's not
>> exactly
>> >> pagination, but it's a similar idea. But currently, with either
>> Edge
>> >> Rails or 1.2, url_for breaks on params generated with
>> form_helpers.
>> >> Specifically, it doesn't handle nested params of the form foo
>> [bar],
>> >> which is what form_helpers generate.
>> >>
>> >> I then found some helper scripts online at
>> >> http://www.marklunds.com/articles/one/314
>> >> This helps retain the correct nested params, but then there is
>> another
>> >> problem with multi-valued selects (and I guess checkboxes).
>> Instead of
>> >> generating urls like:
>> >>
>> >> index?foo[bar][]=1&foo[bar][]=2
>> >>
>> >> with url_for you get one like:
>> >>
>> >> index?foo[bar][]=1/2
>> >>
>> >> Which then is not interpreted correctly later on reentry into
>> Rails.
>> >>
>> >> So, is there a better way to handle this? I'd like to get the
>> >> multi-valued stuff working somehow. Maybe the fault lies in the
>> >> combination of the form_helpers and the url_for (and
link_to), but
>> >> that would seem to be a major blemish on Rails. If I can use
>> all that
>> >> stuff, it makes all of my form elements one-liners, and very
>> easy to
>> >> read and re-use.
>> >>
>> >> Sorry for the novel-length post...
>> >>
>> >> - Michael
> _______________________________________________
> Sdruby mailing list
> [email protected]
> http://lists.sdruby.com/mailman/listinfo/sdruby
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
