I wanted to do something special with “nav” (navigation). The stuff on the left sidebar.
On a shopping site this usually contains a dynamically-changing set of links to help the customer find items of interest.
But that’s fancy code. I wanted something on the left that would submit specific queries of the user’s choosing. But the form of check boxes I had there, as cool as it was in its basic implementation, was not doing what I wanted because I didn’t have time to work out all the code.
I had the form submitting the query arguments to the server in the form of a query string on the URL for the page named in the form’s “action” property, a page I called “art_choice”. This is pretty standard. But if you want the query to be reusable (in other words, the form settings to stay the same) after the first submit, you have to write extra code. Any paging function takes the basic query and adds different limits to it as the user goes through the pages of results. Our pager had nothing built in to save a variable query statement. The query statment was fixed in the list include and would re-run every time a new page was chosen.
I looked on the net and in the text for different ways to deal with saving a variable query. I found the tech of Partial Page Rendering using inline frames and similar methods. The text goes over the use of the $_SESSION variable in PHP for this purpose. And it also mentions the simpler method of saving the data in hidden form elements.
I decided on an unconventional approach using hidden form elements arranged in a table. Each cell in the table would produce a different query result. I like the idea of “laying out all the choices” for a web user, though the concept has its limitations. I could have written code to build the table iteratively each time the page was called, but I didn’t feel like I had the time, so I just wrote out the whole table in HTML and filled each cell in with its unique query string. This works, as far as it goes, with just a little change to the “choice” page which the form buttons all call. I left in echos of some of the strings involved so I could see what was going on “behind the scenes.” This does not include any paging – that was the basic trick. I got the query results down small enough so that none contained more than 6 records.
Total time, including study, about 5 hours.