Sandbox

From FollowTheScore
Revision as of 20:49, 18 August 2009 by Thieh (talk | contribs) (→‎1)
Jump to: navigation, search

feel free to play around

Playground

You must create valid syntax for the gallery extension if you want to use it within DPL; add debug=5 at the beginning of your statement and check what the Template Template:Infobox Country or territory dpl produces. Gero 10:34, 4 April 2008 (CEST)

1

{{#arraydefine:x|

There was a basic version of this extension some time ago. Later it was enhanced by many new features and the name was changed to DynamicPageList2. The new version was no longer downward compatible. At the same time the name of the original extension was changed to 'Intersection' (but the documentation kept talking of DynamicPageList and the tag name still was <DynamicPageList>).

Some time later another bunch of features had been added. And the name was changed back to DynamicPageList (which was thought to be 'free').

Meanwhile some new features had also been added to 'Intersection' and recently 'Intersection' requested its original name back - which caused a real lot of confusion regarding the naming.

Currently (as of June 2009) the status is as follows:

  • Some wikimedia websites like wikinews use the old version. They call it 'Intersection' or 'DynamicPageList'. Its tag is <DynamicPageList> and the sources are in the mediawiki SVN under the path name 'DynamicPageList'.
  • Some other websites switched to DynamicPageList2 - a version which is commonly considered to be obsolete by now. They may want to change to DPL as it is 95% downward compatible with DPL2.
  • Quite a lot of websites use DPL now, i.e. the extension distributed on this website. They call it DPL or DynamicPageList. It uses the tag <dpl> and in addition offers the parser function {{#dpl: ....}}. The source is available here under Download.

There is an opinion which says that running DPL on a major public website would introduce the risk that people write queries which consume a lot of resources. And apart from there is the problem of incompatibilities between 'Intersection' and DPL. 

It is time to put an end to this mess.
  • A large effort was recently put into DPL to make it functionally 100% downward compatible with 'Intersection'. Missing commands were added and the semantics of some existing commands were slightly altered. For details read the chapter on DPL:Manual - Compatibility.
  • A concept of functional restrictions was introduced which allows it to configure DPL with different levels of functionality. The lowest level corresponds exactly to 'Intersection' as of today.
  • An advanced caching concept was introduced which makes it possible to save the result of DPL queries independent from the rest of a page. This means that this DPL cache even survives edit actions of the page containing the DPL invocation - as long as the DPL statement itself is not changed.
So, in near future there will only be one extension named DynamicPageList(DPL) which unites all previous branches.

° In the standard configuration DPL registers the <DynamicPageList> tag. This is needed to be downward compatible with extension 'Intersection'.

In the transition phase you may want to install DPL in PARALLEL to 'Intersection' for testing. DPL offers a second entry point for that purpose. Instead of require_once("DynamicPageList.php") you have to use require_once("DPLMigration.php"). DPL will then ONLY register a tag called <Intersection>

In this constellation you can change some of your existing calls of 'Intersection' (which use the <DynamicPageList> tag) to the <Intersection> tag. Once you are convinced that this produces identical results and works with equal efficiency you can change to require_once("DynamicPageList.php"). Don't forget to change the statements back to the <DynamicPageList> tag!. Of course you must also remove the require_once() for the Intersection extension. °

loop detection
The output of a query will never contain the page which contains the query.
This prevents loops, but in some very rare cases it might not be what you expect.
This is a documented feature; use skipthispage = no to include the page which contains the query. Gero 12:43, 4 December 2009 (UTC)
TOC generation
When using mode=category DPL will switch off TOC generation.
Place a manual TOC pragma in your article if you want to get a table of contents
SECTION editing
When using mode=category DPL will switch off section editing generation.
Place a manual EDITSECTION pragma in your article if you want to get a table of contents

° The general approach to output formatting is two-fold:

  1. There are a couple of simple predefined output formats which generate lists of articles
    You will understand their meaning directly from reading
  2. There is a mode called "userformat" which puts complete control into your hands
    This is somewhat complicated.

While the standard output formats are meant to be used for fast generation of simple page lists, the userformat approach aims at transcluding contents from other pages and requires some effort to understand. There is a system of three tags which are used to enclose (a) the whole output, (b) each item, (c) each transcluded section of an item. A fourth tag is used to separate values between items of one section which occur more than once.

We assume that we have two documents which use templates x and y with varying arguments; while x is being used once within each document, y is used several times. In very short notation the structure might look as follows: 

A: x(a) y(3) y(5)
B: x(b) y(4) y(1) y(2)

The following DPL parameters are used to define a set of tags which are used to construct the output:

The arguments of the above statements can contain references to %VARIABLES%. So sec-1-start might contain a reference like %PAGE% to output the page name. See format for more details on variable substitution.

Now think of the following page inclusion statement: 

 includepage={x}.dpl,{y}.dpl

The output will then look like this: 

 liststart
    itemstart
       sec-1-start
          x.dpl(a)
       sec-1-end
       sec-2-start
          y.dpl(3)
          multi-sep
          y.dpl(5)
       sec-2-end
    itemend
    itemstart
       sec-1-start
          x.dpl(b)
       sec-1-end
       sec-2-start
          y.dpl(4)
          multi-sep
          y.dpl(1)
          multi-sep
          y.dpl(2)
       sec-2-end
    itemend
 listend

Assuming that the tags (liststart, itemstart, etc.) contain wiki syntax for table definitions and multi-sep defines a horizontal line, the output might look like this: 

 +------+---------------------+
 |      |          | y.dpl(3) |
 |  A   | x.dpl(a) |  ----    |
 |      |          | y.dpl(5) |
 +------+----------+----------+
 |      |          | y.dpl(4) |
 |      |          |  ----    |
 |  B   | x.dpl(b) | y.dpl(1) |
 |      |          |  ----    |
 |      |          | y.dpl(2) |
 +------+----------+----------+

In some situations, however, you may want to create an output table where each of the calls of template y is used to create a separate output row. Using a sortable table you could then easily rearrange the output. 

 +------+---------------------+       +------+---------------------+
 |  A   | x.dpl(a) | y.dpl(1) |       |  B   | x.dpl(b) | y.dpl(1) |
 +------+---------------------+       +------+---------------------+
 |  A   | x.dpl(a) | y.dpl(2) |       |  B   | x.dpl(b) | y.dpl(2) |
 +------+---------------------+       +------+---------------------+
 |  B   | x.dpl(b) | y.dpl(3) |       |  A   | x.dpl(a) | y.dpl(3) |
 +------+---------------------+       +------+---------------------+
 |  B   | x.dpl(b) | y.dpl(4) |       |  A   | x.dpl(a) | y.dpl(4) |
 +------+---------------------+       +------+---------------------+
 |  B   | x.dpl(b) | y.dpl(5  |       |  B   | x.dpl(b) | y.dpl(5) |
 +------+---------------------+       +------+---------------------+

There is a special parameter called dominantsection which you can use to mark one section of your includepage statement as "dominant" (in our example: dominatsection=2 as {y}.dpl is the second argument of our includepage statement). You can only have one dominant section in a DPL statement. Marking a section as "dominant" only makes sense if you have multiple calls of the same template (or multiple chapters with the same heading) in your documents. Each piece of content in the dominant section will generate an individual output row with the values of all other columns being repeated.

As all of the above is not very easy to understand there are additional DPL commands (table, tablerow) which make it fairly easy to create tabular output. °° 

 {{#dplmatrix: name | yes | no | mode | '''indented_list''' }}

° 

 (1) {{#dplvar:set    |name1|value1|name2|value2|..|..}}
 (2) {{#dplvar:default|name|value}}
 (3) {{#dplvar:        name}}

° The following example would probably be used directly on an article page, but could also be included as part of a template. Parser extensions define a specific tag (in this case <DPL>) and a corresponding end tag (</DPL>). The text between these tags is handed over to the extension module just as it is.

Example syntax
<DPL>
  category = cat1|cat2
  # only pages which contain a link to myPage
  linksto  = myPage
</DPL>
Parsing procedure

Wiki markup expansion does not take place before the commands are handed over to the extension module.

  • This may be useful if you want to pass wiki syntax elements to DPL2 as arguments (see the format option, for example).
  • Magic words like {{PAGENAME}} or {{CURRENTDAY}} cannot be used.
  • Template calls like {{{some template}}}, cannot be used as parameters.
  • Parser function calls like {{#if:...|...|...}} cannot be used within arguments.
  • To pass wiki syntax elements to DPL as parameters it is sometimes necessary to enforce a line break. The reason is that wiki syntax depends on line breaks. Instead, use \n or for that purpose.
Syntax features
  • Every parameter assignment (=command) has to be on a separate line.
  • Lines starting with a # will be ignored (comment).
  • Generally the syntax looks fairly simple and intuitive as it doesn't contain special characters (except for the two embracing tags).
  • Tag case doesn't matter, so it can also be written <dpl>.
  • In many cases there is no need to have macro expansion within the parameter list. Note that in the example above, the pipe character (which is used to define a logical OR between the two categories) can be written as it is. The name of the page (myPage), however, must be a hardcoded constant.

°

ordermethod Determines what criterium (resp. criteria) is (resp. are) used to order the list.

Syntax:

ordermethod=method1,method2,... means ordered by method1 first, then by method2, etc. (like the ORDER BY clause in SQL)

methodN can be one of the following single tokens:

categoryadd
outputs list based on most recent addition to the first category (requires to include one category and one only using 'category' parameter)
counter
outputs list based on the number of times the page has been viewed (by ~popularity)
size
outputs list based on the size of the article (bytes of wiki text)
firstedit
outputs list based on first edit to the pages (creation)
lastedit
outputs list based on most recent edit to the pages
pagetouched
outputs list based on 'page_touched' timestamp. Read comment on page_touched field in Page_table to see the difference from most recent edit by an author.
pagesel
outputs list based on the names of the reference pages which are used in the selection of a linksfrom or linksto statement. pagesel only makes sense if there is more than one page mentioned in the linksfrom or linksto condition.
title
outputs list sorted by article (prefix +) title
titlewithoutnamespace
outputs list sorted by the article name regardless of namespace — (default)

methodN can also be one of the following token combinations (see also headingmode option):

category,firstedit
outputs list sorted by category, then by first edit
category,lastedit
outputs list sorted by category, then by last edit within a category
category,pagetouched
outputs list sorted by category, then by pagetouched
category,sortkey
sortkey
outputs list sorted by title and sortkey, requires at least one category statement
user,firstedit
outputs list sorted by user, then by firstedit by the user
user,lastedit
outputs list sorted by user, then by lastedit by the user
none
do not apply any ordering (except ordering by timestamp if you requested a list of revisions); this method must be used when you specify openreferences=yes.

Note: For downward compatibility reasons DPL will use 'addfirstcategory' as its default order method if called via the <dynamicPageList>

Example: 

<DPL>
  category=Africa
  ordermethod=lastedit
</DPL>

This list will output pages that have [[Category:Africa]] showing most recently edited articles at the top. °°|°}} {{#arraysort:x|random}} {{#arrayindex:x|0}}

3

  • Cameroon
  • Align=right

    475,442

  • Align=right

    923,768

  • Align=right

    637,657

  • Align=right

    2,505,813

2

Country Official Name Capital Dial Code
DPL Example 007 main page 1 (%COUNT%) Template:Country dpl.default
Nigunda (%COUNT%) Republic of Nigunda Bamitogoo 237
Nigunda Test (%COUNT%) Republic of Nigunda Test Bamitogoo Test 237
Somango (%COUNT%) Somango Island Aaaabququque 224

Number of data = 1

No Name Languages Government Area Population GDP Independence Day
1 Republic of Cameroon French,English Republic 183,568 sq mi 17,795,000 $43.196 billion 01/10/1961

%TOTALPAGES%

{{#dpl: category=African_Union_member_states¦Cities|resultsheader=%PAGES%|noresultsheader=none|mode=userformat

9 

{{#dpl: category=African_Union_member_states¦Cities|resultsheader=%TOTALPAGES%|noresultsheader=none|mode=userformat

9

1 3.2.1 

 good morning!
Retrieved from "http://followthescore.org/dpldemo/index.php?title=Sandbox&oldid=13770"