ITC280 – brute-force nav page

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.

One Response to “ITC280 – brute-force nav page”

  1. Bill Says:


    Thanks so much for all your hard work this quarter! You did an awesome job!

    As I look at the work you’re undertaking above, if you want something to be linkable, I believe you can store the current value of the Qstring thus:

    $oldQstring = $_SERVER[‘QUERY_STRING’]

    Or something like that. Then you can add your own parameters and retain the pager parameters, etc:

    myRedirect(‘mypage.php?myval=blah&’ . $oldQstring);

    Not sure if this is barking up the right tree or not, but I bet you’ll find it useful some time!

    Thanks again for all the hard work this quarter!

    Keep in touch!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.