Difference between revisions of "Issue:Includematch parameter regexp issue"
(→Reply) |
(→Reply) |
||
Line 68: | Line 68: | ||
The <tt>includematch</tt> parameter uses the comma as a separator. Each comma delimited token is matched against its corresponding parameter from the <tt>include</tt> statement. The first comma in your argument is taken as a separator and then DPL complains about a missing trailing "/" in "/project\s*=\s*([^" which is quite reasonable, isn´t it? | The <tt>includematch</tt> parameter uses the comma as a separator. Each comma delimited token is matched against its corresponding parameter from the <tt>include</tt> statement. The first comma in your argument is taken as a separator and then DPL complains about a missing trailing "/" in "/project\s*=\s*([^" which is quite reasonable, isn´t it? | ||
− | Try to escape the comma by using &#number syntax. Defining a Template:Comma which produces a comma might also work if you use ²{Comma}² for expansion. | + | Try to escape the comma by using &#number syntax. Defining a Template:Comma which produces a comma might also work if you use ²{Comma}² for expansion. But I am not really sure if one of my suggestions works. On one hand DPL shouldn´t see the conmma, on the other hand a real comma should be passed to the regexp. Maybe it is a conceptual issue and DPL should be more flexible in its way tro separate arguments into tokens. Please do some experimenting (ideally with a showcase here in this wiki) and come back ... |
[[User:Gero|Gero]] 18:32, 12 October 2007 (CEST) | [[User:Gero|Gero]] 18:32, 12 October 2007 (CEST) |
Revision as of 17:37, 12 October 2007
Description: | includematch parameter does not work with complex regexp |
Extension / Version: | DPL / 1.4.7 |
Type / Status: | Bug / answered |
Problem
I have the following templates: Template:Todo with the following code
Do task for project {{{project}}}
where the project= option is a comma separated list of projects to which this particular TODO is associated with (see below for valid variations of project option). I also have the following template Template:Todo.dpl with the following code
<includeonly> * {{{1}}} </includeonly>
I want to write a DPL query to display only the tasks assigned to a particular project (let's call it myproj).
I tried doing the following
<dpl> uses=Template:Todo include={Todo}.dpl includematch=/project\s*=\s*([^,]*,)*\s*myproj\s*(,[^,]*\s*)*$/i </dpl>
However, when I view a page with this DPL code, I get a LOT of error messages similar to Warning: preg_match() [function.preg-match]: No ending delimiter '/' found in /export/www/html/npdwiki/extensions/DynamicPageList/DynamicPageList2Include.php on line 429 and the results are not correct: the query does not display any matches.
The following PHP code demonstrates the application of this template to match against several valid and invalid options for project= parameter.
<?php $test = array(); array_push($test, "project=myproj"); array_push($test, "project = myproj"); array_push($test, "project = blah, myproj"); array_push($test, "project=blah , myproj"); array_push($test, "project = blah blah blah , myproj "); array_push($test, "project = myproj, blah blah"); array_push($test, "project = blah , myproj , blah"); array_push($test, "project = myproj two"); array_push($test, "project = blah, myproj two, blha"); array_push($test, "project = myproj ,myproj two"); array_push($test, "project = myproj two , myproj"); foreach ($test as $t) { print "testing '$t' ==> "; if (preg_match('/project\s*=\s*([^,]*,)*\s*myproj\s*(,[^,]*\s*)*$/i', $t)) print "match \n"; else print "NOT matching\n"; } ?>
- --Gri6507 16:05, 12 October 2007 (CEST)
Reply
The includematch parameter uses the comma as a separator. Each comma delimited token is matched against its corresponding parameter from the include statement. The first comma in your argument is taken as a separator and then DPL complains about a missing trailing "/" in "/project\s*=\s*([^" which is quite reasonable, isn´t it?
Try to escape the comma by using &#number syntax. Defining a Template:Comma which produces a comma might also work if you use ²{Comma}² for expansion. But I am not really sure if one of my suggestions works. On one hand DPL shouldn´t see the conmma, on the other hand a real comma should be passed to the regexp. Maybe it is a conceptual issue and DPL should be more flexible in its way tro separate arguments into tokens. Please do some experimenting (ideally with a showcase here in this wiki) and come back ...
Gero 18:32, 12 October 2007 (CEST)