Difference between revisions of "DPL Example 027"
From FollowTheScore
| Line 6: | Line 6: | ||
* When scrolling forward we use ascending order; when scrolling backward we internally use descending order but we reverse the result set for the user | * When scrolling forward we use ascending order; when scrolling backward we internally use descending order but we reverse the result set for the user | ||
* Each query takes a lower or an upper limit for the search as a selection criterion; This criterion is set by an URL parameter which is deducted from information of the previous query: each query passes the first and last page of its result set to a [[Template:Extension DPL continue|scroll helper template]]. | * Each query takes a lower or an upper limit for the search as a selection criterion; This criterion is set by an URL parameter which is deducted from information of the previous query: each query passes the first and last page of its result set to a [[Template:Extension DPL continue|scroll helper template]]. | ||
| + | * The command <tt>scroll=yes</tt> is needed to enable scrolling. | ||
* The approach could be extended: The scroll helper could produce a set of fixed links for the initial letters; thus one could easily jump to A, B, C, ... | * The approach could be extended: The scroll helper could produce a set of fixed links for the initial letters; thus one could easily jump to A, B, C, ... | ||
| − | |||
* Note that adding %TOTALPAGES% to ''resultsheader'' or ''resultsfooter'' would lead to a SQL statement which might be less efficient as the database must each time calculate the total number of matching records ("SQL_CALC_FOUND_ROWS") | * Note that adding %TOTALPAGES% to ''resultsheader'' or ''resultsfooter'' would lead to a SQL statement which might be less efficient as the database must each time calculate the total number of matching records ("SQL_CALC_FOUND_ROWS") | ||
* The time spent within DPL is displayed at the bottom; usually it is below 30 msec. | * The time spent within DPL is displayed at the bottom; usually it is below 30 msec. | ||
Revision as of 05:55, 4 October 2009
back to list of examples
Optimum performance result scrolling for huge wikis
This page demonstrates how DPL can be used in really huge wikis like WIKIPEDIA to allow efficient scrolling through huge result sets. The approach ios very much straight forward:
- We use count=50
- When scrolling forward we use ascending order; when scrolling backward we internally use descending order but we reverse the result set for the user
- Each query takes a lower or an upper limit for the search as a selection criterion; This criterion is set by an URL parameter which is deducted from information of the previous query: each query passes the first and last page of its result set to a scroll helper template.
- The command scroll=yes is needed to enable scrolling.
- The approach could be extended: The scroll helper could produce a set of fixed links for the initial letters; thus one could easily jump to A, B, C, ...
- Note that adding %TOTALPAGES% to resultsheader or resultsfooter would lead to a SQL statement which might be less efficient as the database must each time calculate the total number of matching records ("SQL_CALC_FOUND_ROWS")
- The time spent within DPL is displayed at the bottom; usually it is below 30 msec.
Extension:DynamicPageList (DPL), version 3.2.1: Warning: No results.
{{#dpl:
| namespace =
| category = Events
| count = {%DPL_count:50%}
| resultsheader = ²{Extension DPL continue¦dir=%SCROLLDIR%¦pages=%PAGES%¦total=%TOTALPAGES%¦firsttitle=%FIRSTTITLE%¦lasttitle=%LASTTITLE%¦page={{FULLPAGENAME}}}²\n
| resultsfooter = ²{Extension DPL continue¦dir=%SCROLLDIR%¦pages=%PAGES%¦total=%TOTALPAGES%¦firsttitle=%FIRSTTITLE%¦lasttitle=%LASTTITLE%¦page={{FULLPAGENAME}}}² %DPLTIME%\n
}}
