[development] How to pass form values to page that actually does something.

[Bayne, Sam]

We're doing testing with option A.

The idea of using the md5 for query_id is a good one for saving space in the database, but we actually want to prevent caching on the client.
That's why we went with option A in the first place.

This also has opened up the idea of saving recent or favorite searches per user or session.
In the meantime, we're timestamping the queries, and we can clear out old ones with cron.

On May 10, 2010, at 9:52 AM, Alex Bronstein wrote:

> I like your option A. You can either store the SQL query string, or be a little more like the search module and store the relevant portion of $form_state['values'], and allow the code in the redirect page to build the query from that.
> 
> In either case, you can make the query_id or input_id be the md5() of what you're storing. That way, multiple submissions with the same options (whether from the same person or from different people) don't flood the table with essentially duplicate records. And it allows the page to be more effectively page cached (i.e., a particular set of options always results in the same URL of the redirect page).
> 
> Alex.
> 
> Bayne, Sam wrote:
>> I'm quite frustrated with the Form API right now, so please forgive my tone.
>> 
>> I've got a form that has a bunch of inputs, all of them multiselects, that allow the user to choose what classes to see in our schedule.
>> (our class schedule is in an external database).  I've got a bunch of code in the form_submit function that builds a very elaborate sql query to get the list of requested classes.
>> 
>> Unfortunately, the form_submit function is not actually permitted to display anything except through drupal_set_message().
>> 
>> So I have to either pass my complicated sql query, or all the contents of the form fields to some other page through $form_state['redirect'].
>> 
>> How do I do that without shoving it all into the querystring?
>> 
>> Right now, I'm looking at the performance issues of:
>> 
>> A: storing the query as a string in the database with a query_id, then sending a query_id in the redirect,
>> B: storing the result of the query in the database with a result_id, then sending a result_id in the redirect.
>> 
>> Is there some other way to accomplish what I want?
>> 
>> p.s. I've looked at the search module, it basically shoves the form input into the querystring of the redirect. That'll work for a single input, but multiple array inputs will be a huge pain.
>> 
>> 
>>  
>