PHP Page 3 - Creating a Searchable Inventory System: Setting Up Your Database and User Interface (continued) |
Since any web search begins with a search form, it is appropriate that our helper Search class begins with the “get_search_field” function. We’ve already defined all of the information required to create that function within our “inc.conf.php” file, so let’s take a look at the code and how it will work: function get_search_field( $p_search_field_name ) { # retrieve search field information from GLOBALS # check session for pre-set search field value # retrieve any additional pre-set HTML attributes # properly format field name before continuing # if field is of type select, then return a SELECT # open select tag # append (empty) "Any" option # retrieve all appropriate OPTIONs from DB # retrieve SQL values # check to see if current option # append OPTION tag } # END for each result } # END if results found # close select tag # if field is of type text, then simply return a TEXT # return a text input field } # EBD 'field_type' check # return HTML } # END get_search_field() As you can see, we not only completed the “get_search_field” function, but we also introduced an additional helper function, “get_field_session_value”. Let’s take a quick look at it, and its matching “set_field_session_value” function, before continuing: function get_field_session_value( $p_search_field_name ) { function set_field_session_value( $p_search_field_name, The purpose of the “get_field_session_value” function is simple: to retrieve a user-defined value for the particular field of choice, if any, from the SESSION. As the user runs a search, the value specified for each search field will be stored within the SESSION (using “set_field_session_value”). Then as the page is re-drawn PHP will pre-select the value(s) previously provided by the user. This step is not necessary, but will help to avoid any confusion in the mind of the user as he or she uses our search form. Now back to the “get_search_field” function. As you can see, this function is comprised mostly of comments, so it should be relatively self explanatory. First we retrieve the array from the configuration file, then using the values we have defined for each menu object, we create the appropriate field. If the field should be a SELECT menu, we also retrieve a list of appropriate OPTION tags using the query specified in the configuration array. There are only a couple of items which may cause confusion. The first deals with the SELECT menu query, “pre_populate”. In order to keep our helper function(s) as simple as possible, this query must retrieve its resulting SQL information in the form of two fields: “value” and “display”. The “value” field is used to populate the “value” attribute of our HTML OPTION tag, while the “display” field is used to actually display the information to the user. In other words, if the query retrieves a record with the display field of “Bob” and a value of “3”, “Bob” is what is shown to the user but “3” is the value submitted when a new search is triggered. Secondly, two of our fields specify a “parent_menu” name, “Categories”. As our helper function retrieves the SQL query used to populate these search menus with a list of OPTION tags, it also checked the “parent_menu” field’s session value (using the helper function “get_field_session_value”). Since our “Sub Categories” and “Manufacturers” menus depend on values found within “Categories”, we don’t want to load them by default –- but instead, only when a “Categories” value is provided. However, if a “Categories” value was provided in a previous search, then we want that value to be open by default as the page is displayed. By replacing a special placeholder string, “<<field>>”, with any pre-specified value of the parent “Categories” menu, we are able to ensure that the appropriate list of OPTIONs is initially displayed. This brings us to our next point. Some of our “populate_query” values contain the sub-string “<<field>>”. As you may have noticed, our helper function replaced that string with a dynamic value at run-time. The purpose of this is to allow our SELECT menus the option of being dependent upon each other using user-specified values. Our query, then, sets up all of the information necessary to allow for that interaction, except for the actual value of the key itself. That is provided at run-time as the user selects a “Categories” menu option. Finally, our function removes any potential spaces from a field name before creating a corresponding HTML entity. This is done to prevent breakage in the way POST values are submitted for fields containing spaces in their names. You may see the effects of our “get_search_field” function by inserting the following code into the “index.php” file. (This code should be inserted where the previous “<!-- … Menu here -->” placeholders were located.) <?php $search = new search(); ?>
blog comments powered by Disqus |
|
|
|
|
|
|
|