Home arrow PHP arrow Page 3 - Creating a Searchable Inventory System: Retrieving and Managing Search Results (continued)

Explaining the Function - PHP

In this article, we will set up an automatic search listener to execute the code for our searchable inventory system. With this final piece, we will assemble all of the parts of our application into a working search tool. It will allow us to search for records using any combination of the search forms, as well as sort those records by almost any of the resulting column headers.

TABLE OF CONTENTS:
  1. Creating a Searchable Inventory System: Retrieving and Managing Search Results (continued)
  2. Automatic Search Listener
  3. Explaining the Function
  4. Displaying Search Results
By: Brian Vaughn
Rating: starstarstarstarstar / 4
November 29, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

First, our function checks to see whether our search form has been submitted. If this is the case, it re-sets our additional WHERE constraints to NULL using the “set_where_constraints_value” helper function. This gives us a clean slate to work with. Next, it walks through each search field specified within the GLOBAL search array, and checks for that field’s posted value.

Note: As a reminder, the name of the search field should be stripped of any white space before continuing to prevent any possible breaks in our POST array.

As each field’s value is checked, it is also stored within the session using our “set_field_session_value”. This will enable us to pre-select the appropriate values for this field as the search form is re-drawn. Additionally, if a non-empty value was specified for this field we will also want to append it to the WHERE portion of our search query. To do this, we will use the “search_pattern” specified in our configuration file, and simply replace the placeholder “<<field>>” with the user-specified value.

This pattern was not discussed in too great a detail when we first introduced it. In fact, it may be self-explanatory to many of you. The basic purpose of the “search_pattern” is to allow our search tool to use the search criteria provided by our user in an intelligent manner. For instance, our “Categories” menu then simply links a primary key to an indexed record, but our “Keywords” field allows the user to search for a partial match in either the “Name” or “Description” field of our database. This allows our search tool to be much more flexible and useful.

Finally, our function re-sets the current results page to the first page. This is an important step in a new search, as there is no guarantee that a new search will have as many results as the previous one. Most importantly though, this allows our search tool to work in a more intuitive way for the end user.

The next major block of code within our “init_search” function deals with record sorting. If a user has chosen to sort the results by a certain field, this portion of our search class will record that action so that our “get_search_results” function is easily able to integrate it into the SQL query. To do this, it simply stores the order-by field and direction within the SESSION, using the helper functions we defined earlier. This function also re-sets the current page of records to the first one, as page X sorted by Category has no meaning when compared to page X sorted by Sub Category. (There’s no correlation between the two.) Because of this, we’ll want to re-set the records to page 1 each time a new sort-action is applied.

Next our “init_search” function checks for a new pagination selection. When a user clicks one of the hyperlinks found within our pagination menu, this section of code is triggered, and the page specified is stored within the SESSION using our helper function “set_limit_start_value”.

After all of the IF statements have finished executing, and the newest query information has been stored within the SESSION, one final block of code must still execute. This block will be vital to other functions within our search class, such as the previously introduced “get_search_results” and also the pagination menu functions which we will deal with in a later article. The code we are referring to simply retrieves a count of all records matching the search criteria provided using the GLOBAL variable “db_base_count”. This count is then accessed using the helper functions listed below:

      function get_total_record_count() {
            return ( !empty( $_SESSION
['db_total_record_count'] ) ) ? $_SESSION
['db_total_record_count'] : 0;
      } # END set_total_record_count()

      function set_total_record_count( $p_total_record_count ) {
            $_SESSION['db_total_record_count']  =
$p_total_record_count;
      } # END set_total_record_count()



 
 
>>> More PHP Articles          >>> More By Brian Vaughn
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PHP ARTICLES

- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: