Issue:Category option that does AND operation to multiple parameters

From FollowTheScore
Jump to: navigation, search
Description:
Extension / Version: DPL   /   1.6.7
Type / Status: Change Request   /   closed

Problem

I made a small enhancement to DPL to support a 'categoryall' option. Given multiple parameters it does an AND operation on them instead of an OR. The reason for doing this is I'm generating the DPL query dynamically and I couldn't see a way of creating multiple 'category' options - it's much easier working with a simple list.

It's a bit simplified compared to 'category' - it doesn't handle the '+', '-' or '*' modifiers, but for your consideration please find the patch below ...

Eclecticdave 14:59, 1 March 2008 (CET)

diff --git a/DynamicPageList2.php b/DynamicPageList2.php
index bc02203..6d391b2 100644
--- a/DynamicPageList2.php
+++ b/DynamicPageList2.php
@@ -344,6 +344,7 @@ class ExtDynamicPageList2
          * @todo define 'category' options (retrieve list of categories from 'categorylinks' table?)
          */
         'category'             => NULL,
+        'categoryall'          => NULL,
         'categorymatch'        => NULL,
         'categoryregexp'       => NULL,
         /**
@@ -1371,6 +1372,17 @@ class ExtDynamicPageList2
                         $bConflictsWithOpenReferences=true;
                     }    
                     break;
+                case 'categoryall':
+                    $aParams = explode('|', $sArg);
+                    foreach($aParams as $sParam) {
+                        $sParam=trim($sParam);
+                        if($sParam == '') {
+                            // Include uncategorized pages
+                            $bIncludeUncat = true;
+                        }
+                        $aIncludeCategories[] = array($sParam);
+                    }
+                    break;
                     
                 case 'notcategoryregexp':
                     $sNotCategoryComparisonMode = ' REGEXP ';
@@ -3933,4 +3945,4 @@ class DPL2Logger {
 
 }
 
-?>
\ No newline at end of file
+?>

Reply

As the manual states (see category) you can have multiple lines with "category="; together they will act as an AND condition. It looks to me as if your change tries to do the same?

Gero 21:32, 1 March 2008 (CET)

Yes, absolutely. The problem comes when I'm trying to autogenerate multiple category= lines using StringFunctions (your modified version with regexp support).

I started with a (non-escaped) template invocation where the category= lines should go and tried using #replace to create them. But you can't put a pipe character in the replacement string of a #replace statement which was causing me headaches with this approach. (Later it occurred to me it might work if #replace supported the \p escape used by CharacterEscapes, but I'd already written categoryall by then :-)

I'm trying to build up a DPL query through the user clicking on a succession of category links. If a concrete example will help, you're welcome to take a look at my website-in-development [1]. Click on one of the categories at the top right of the Main Page to get to the "Category Browser".

Eclecticdave 12:32, 2 March 2008 (CET)
Just a short hint: Putting a pipe in the replacement character of #replace is possible if you use a template to create the pipe symbol:
replacing in 'a,,b,,,c' one or more commas by a single pipe yields: {{#replace:a,b,c|/,+/||}}
source is {{#replace:a,b,c|/,+/|{{!}}}}
Have you seen Template:Catlist? Maybe you can use tghis as a starting point for your category browser. It would be fairly easy to add a second and third category selection box ...
Gero 12:52, 2 March 2008 (CET)

Odd Behaviour With Pipe Characters

Thanks, I tried it with the {{!}} template and it does indeed allow me to create a string containing pipe characters.

However, when including the result into DPL it doesn't seem to do the expected thing. The replace correctly expands but the pipes aren't being parsed properly.

Here's an example - the output is produced by uncommenting the return statement at line 866 of DynamicPageList2.php ...

If I use a straightforward DPL statement like this :

{{#dpl:category=Fred|category=Joe|category=Harry}}

DPL sees this (as expected) ...

category=Fred
category=Joe
category=Harry

But, if I try to dynamically generate the category lines from a '!' delimited string (which in practice would be a template parameter) like this ...

{{#dpl:category = {{#replace:Fred!Joe!Harry|/!/|{{!}}\ncategory = }}}}

DPL sees this instead ...

category = Fred|category =Joe|category =Harry

What seems to be happening here, is MediaWiki has already parsed the parameters into arguments to pass to DPL before expanding the template. Which prevents DPL from seeing the multiple category lines as separate entities.

What do you think? If I'm right, the implication is that a template within a parser function cannot be used to represent multiple arguments.

Eclecticdave 02:11, 3 March 2008 (CET)

Reply

As far as I can see you are perfectly right. Obviously you can´t have a parameter which explodes into many other parameters which are immediately understood as separate parameters. There seems to be some "outward-in" approach in the wiki parser and not an in-depth-tree-walking approach.

21:28, 3 March 2008 (CET)

Small Fix

I can't decide from your reply whether or not I've convinced you that my enhancement is useful? So I'll press on under the assumption that you're still considering it ;-)

I've made a small fix - it wasn't normalising the category names. The following patch should be applied on top of the original patch above...

Eclecticdave 00:21, 5 March 2008 (CET)

diff --git a/DynamicPageList2.php b/DynamicPageList2.php
index 6d391b2..75cff3b 100644
--- a/DynamicPageList2.php
+++ b/DynamicPageList2.php
@@ -1380,7 +1380,8 @@ class ExtDynamicPageList2
 							// Include uncategorized pages
                             $bIncludeUncat = true;
                         }
-						$aIncludeCategories[] = array($sParam);
+						$title = Title::newFromText($localParser->transformMsg($sParam, $pOptions));
+						$aIncludeCategories[] = array($title->getDbKey());
                     }
 					break;
                     

Adoption

After some consideration I decided to introduce the "&" operator in the normal category command. This avoids another new keyword and should be closer to what the average user expects. Thanks for your input. Improvements are always welcome.

Gero 22:53, 8 March 2008 (CET)


Sorry, took me a while, but I just got around to upgrading. I'm pleased to report your version does the job just as well as mine ;-) Many thanks.

Eclecticdave 15:44, 15 March 2008 (CET)