Difference between revisions of "Talk:Test includematch"

Latest revision as of 10:07, 1 April 2009

Includematch searches all fields instead of just one (bug?)

I tested the following example and noticed strange includematch behaviour.

<dpl>
category=African Country
includepage={African Country}:languages,{African Country}:goverment,{African Country}:area,{African Country}:population,{African Country}:gdp,{African Country}:independence_day
mode=userformat
listseparators=¶{|class=sortable ¶!No ¶! Name ¶! Languages ¶! Government ¶! Area ¶! Population ¶! GDP ¶! Independence Day , ¶|-¶|%NR%¶|[[%PAGE%]] , ,¶|}
secseparators=¶|
resultsheader=Number of data = %PAGES%
includematch=/languages\s*=\s*.*English.*/s
</dpl>

Try for example replacing

includematch=/languages\s*=\s*.*English.*/s

with

includematch=/languages\s*=\s*.*1961.*/s

and you still got a result because the "Independance day" column is searched. Shouldn't only the "Languages" column being searched? --Mark P. 23:25, 22 November 2007 (CET)

Reply and Explanation

First, the DPL statement above could be written more elegantly, using the table command. The table command was invented recently to facilitate standard view definitions.

Second the regexep uses ".*" before 'English' or '1961'. This means that also pipe characters will be skipped - so '1961' will be accepted if it occurs ANYWHERE AFTER 'languages'. What you want, however, is to stop the pattern matching at field boundaries /(i.e. at pipoe characters). Therefore you must use [^|]* instead of .* which will match all characters EXCEPT The field delimiting pipe character.

Third, the '.*' AFTER 'English' is useless and should be left away.

<dpl>
 category=African Country
 namespace=
 include={African Country}:languages:goverment:area:population:gdp:independence_day
 includematch=/languages\s*=\s*[^|]*English/s
 table=class=sortable,Name,Languages,Government,Area,Population,GDP,Independence Day
 resultsheader=Number of data = %PAGES%\n
 noresultsheader= no matching country found.\n
</dpl>

And here is the result with 'French':

Number of data = 3

.. and with '1961'

Number of data = 1

Note: If you use the #dpl parser function notation you must not use the pipe directly because it would be misperceived as a field demiter for #dpl itself. In that case you should use something like [^{{!}}]* (assuming that there is a template called ! which returns a single pipe character.

Gero 12:13, 24 November 2007 (CET)

Thank you for this clear explanation. --Mark P. 22:35, 24 November 2007 (CET)

Similar Application - need direction

attempt on the Template:Person page

1. Person is a template that has a parameter Name(which is set to the Person's name- simple right?)
2. Servers is a template that has a parameter Admin1 (which is hard coded to a Person's name)
3. We are attempting to query Servers (of Template:Servers) with Admin1=Name (the person's name from {Person}:Name)
4. this dpl tag set is located in Template:Person.

<DPL>
 category=Server|Person
 notnamespace=Template
 include={Servers}:Status
 includematch=/Admin1\s*=\s*[^|]*{{{Name}}}/s
 table=class="sortable server_attribs",Name,Status
 resultsheader=Number of data = %PAGES%\n
 noresultsheader= No servers administered.\n
</DPL>

1. There is no need for category=Person. You should only look for "category=Server" I think.
2. The matching term for the Admin1 looks good -- in THEORY ;-)
3. But be careful: Wiki variables like "Name" are only expanded within parser function calls. So the above example will NOT work!

attempt on shmo's page

1. shmo is a Person (Template:Person)
2. attempting to use a harded coded value of "shmo" to match to {Servers}:Admin1 (shmo can be hard coded here since it's his page and no one elses)

{{#dpl:category=Server|includematch=/{Servers}:Admin1\s*=\s*shmo/s|notnamespace=Template}}

--Uncg 23:08, 15 December 2007 (CET)

1. This statement is a parser function call (although this is not necessary in this case as "shmo" is hardcoded. But it LACKS the INCLUDE statement!

Try to read the manually carefully! -- And sign your contributions, please! 22:03, 15 December 2007 (CET)

Sorry about missing the include - please understand I had copied and pasted it from about 12 different attempt sections where I was learning and playing with DPL for the first time today. I made the following change and got great results.

{{#dpl:category=Server|include={Servers}:Admin1|includematch=/Admin1\s*=\s*shmo/s|notnamespace=Template|table= class="sortable server_attribs",Server, Admin}}

Desirable final touches include removing the redundant mention of the admin (who's page I am viewing at this state).

Also I have been looking over the manual for some time now but cannot find a method that would allow me to include this functionality (whether it be a parser function call or a parser extension) in a template. Originally my goal was to generalize this function in a template so that it would list the servers the person administers or display "no servers administered". I have found a way to accomplish this using categories, but it's kind of kludge and it causes links to not appear corretly when displayed in a table (the template sets the parameter admin1 as [[{{{Admin1}}}]]) but fine any other time it is requested. I believe this is because of my usage of the include={template}:parameter syntax - to which i see no alternative. --Uncg 23:25, 15 December 2007 (CET)

try "format=," to suppress any output except the included contents.

if you do this you will get NO output at all if a document does not match your condition.

Gero 00:02, 16 December 2007 (CET)

includenotmatch with multiple expressions

Hi,

i have to exclude multiple expressions from my resultset like in:

<dpl>
  category = African Union member states
  includepage={Infobox Country or territory} dpl,
  includenotmatch =/native_name\s*=\s*Federal Republic of Nigeria/s,/common_name\s*=\s*Cameroon/s
</dpl>

• Cameroonalign=right|475,442 |align=right|16,323,000
• Somaliaalign=right|637,657 |align=right|8,228,000
• Sudanalign=right|2,505,813 |align=right|36,992,490

I expected the result to be a list of countries where none of the two regular expressions is matched, but it seems that only the first expression is evaluated. How is this done properly? Or is it a bug in DPL? --Jailing1 09:07, 1 April 2009 (UTC)