|
|
 |
Join us on FaceBook | |
 |
Submit Your Code | |
 |
Poker Tournaments | |
|
Poker Guide for Developers | |
 |
SEO Monitor | |
 |
UpTime Monitor | |
 |
My Favorite Examples | |
|
My Favorite Articles | |
 |
Update Your Profile |
| More Weber Sites | ||
| PHP Code Search | ||
| Web Development Forums | ||
| Learn MySQL Playing Trivia | ||
| PHPBB2 Templates | ||
| Web Development Resources | ||
| Web Development Content | ||
| Internet Security Software | ||
| Recommended Links | ||
| PHPClasses | ||
| PHP Editor | ||
| PHP Jobs | ||
| Vision.To Design | ||
| Ajax Tutorials | ||
| PHP Programming Help | ||
| PHP/MySQL Programming | ||
| Webmaster Resources | ||
| Webmaster Forum | ||
| XML meta language | ||
| website builder | ||
| Recommended | ||
| פרייסז - הכח לקנות עובר לידיים שלך | ||
| Texas Holdem Poker Evangelists | ||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Code | |||||||||||||
This is a demo of a model for pagination that differs from others. It has many features that distinguish it from other methodologies, not the least of which is multiple selection of items in the pages. Another feature is that it does not suffer the limitations of html requests lengths, since it uses sessions. Also, it does not go to the database 'well' for each page. Typically, for a given set of access parameters, it only accesses the database once, caching away the results in a session variable. Paging is thus more fluid. It also uses HTML form submit buttons, in conjunction with a select for page 'jumps', to page through the document as opposed to hyperlinks. This makes for cleaner code in general. The demo consists of 5 files: A driver (simulates the caller in a website hierarchy); The paginator code; The strings that PHP prints to construct the HTML page; The processor (simulates the final processing in a website hierarchy); The database (simulates, say, a MySQL database contents). These are paginationDriver.php, pagination.php, printStings.php, process.php, and database.php respectively. The strings that create the HTML code are in a separate file so as not to obscure the PHP pagination logic in pagination.php. This is not really necessary, but it does make the code easier to read. Do as you wish with your own implementation. The code logic revolves around a set of variables: $jobTitle; $sortOrder; $sequence; $pageLen; $curPage; $totalCount; $itemList. There are, of course, others, but these are really the important ones. The first three, $jobTitle, $sortOrder, $sequence, are selector categories in the menu. The value returned by these says how to access the data. $pageLen is the number of items to show per page. $curPage begins as the page last viewed by the user and in the process of the pagination logic changes to the page which will be viewed. $curPage is used in 2 places in the code as an index into the selected $itemList in conjunction with $pageLen. Be careful with where values are assigned to $curPage! Reassigning to the value of the page which will be viewed in the wrong place in the code execution will break the code! $totalCount is the total number of items currently selected from the database. $itmeList is the actual list selected from the database. It only changes when the user specifies new criteria through the selector categories in the menu. One other variable controls how the paging takes place, that is $btnVal. In the form there are 5 buttons: Next; Prev; Go To; Process Selections; Cancel. These are all assigned the name 'btnVal'. On reentry into pagination.php, this value is examined. If it is Next, Prev, or Go To, a value is assigned to $curPage indicating the page which will next be seen by the user. If the value is Next, $curPage is incremented unless it is already equal to the last page, in which case it is set to 1. If the value is Prev, $curPage is decremented unless it is already equal to 1, in which case it is set to the last page. If the value is Go To, $curPage is simply set to the value returned in the select as 'pageNum'. This is one of the unique properties of this methodology, it allows the user to page backwards, forwards, or 'jump' to any page. Most methods that use hyperlinks only allow a proximity range for 'jumps'. Of course, if you have a very large database that can select a huge number of pages, another algorithm needs to be used, such as every other, 3rd, 4th, etc. page., but still, it's more flexible than the proximity range method. As the user pages through the selections, he may choose to have one of the selections processed by choosing the select next to the first field in the table row. This is saved in the $itemList as a boolean (true, false) and thus the user choices are preserved from page to page. This is another feature where this design differs from most. In the hyperlink method, the user generally selects a link in the item he wishes to process. This then goes to another page to process the choice. This means that the user's train of thought is interrupted, not to mention the continuity of the paging process. It also means that processing code must be called for each selection individually. With the method outlined in the demo, all selections are processed at the same time, i.e., when the user has finished making choices. The final 2 elements in the paradigm are how the user chooses to terminate their browse of the selections: process or cancel. These are the other two buttons used in the form that have the name 'btnVal'. On reentry into pagination.php, $btnVal is checked to see if it is a termination value, i.e. 'Process Selections' or 'Cancel'. Cancel is simple, just destroy the session and return to the web page in the hierarchy that called the paginator code. The other choice is more involved but not overly so. The model just checks for at least one 'true' in the $itemList. If one is found, we proceed to the processor code, if not, we simply return to pagination.php to let the user either continue or cancel. The last step is, of course, doing whatever processing is required for the user's selections. The stub, process.php, illustrates this step. Of course, there are more algorithms which can be used to adapt this paradigm to a specific use. One obvious one is the case of an extremely large database with hundreds (thousands?) of entries. An algorithm might be put in place here that ascertains the total number of entries and chops them into manageable sections, going back to the database 'well' whenever the next page to be viewed is outside the current cache. But the basic principles of reduced database access and multiple selection are still in force. To see a 'live' implementation of this paradigm, visit http://www.wxcodex.net/. This is the site for which I developed the design. Hope you find this useful!;) thx, Dave S. Dave Silvia You can find all of the files attached to this code example (at the begining of the example). pagination.php
| |||||||||||||
| Related Code Examples | |||||||||||||
|
| |||||||||||||
