WikiPatches/MagicPages

This patch adds general MagicPage functionality.

This is work in progress. It works :-) but it doesn't do anything yet, except add something to the bottom of a page named Foobar (if you have one).

-- tarquin

Superseded by WikiPatches/MagicContent

Plans

Things this patch could do:

• Include SunirShah's Wanted Pages script -- see WikiPatches/MagicWantedPages
• provide some sort of system for generalized page names, so pages of the form Category* are all magic, with the same script
• refactor the RecentChanges code into the module. However, this needs to read the $RCName variable, since the site user can change the actual name of the RecentChanges magic page.

How it works

To add a new magic page, add a new package in the module. Just make a copy of package Foobar and use it as a template. Replace instances of "Foobar" with the name of your magic page -- this is the name of the Wikipage where the script will run (though I've not yet checked what to do with freelink pages with spaces in them.... potential bug alert!). Add your script into sub GenerateContent?.

Patch

In wiki.cgi

add this line before "package UseModWiki;"

 use MagicPages? ;

in sub BrowsePage, below the block of "if (($id eq $RCName) .....", add this line:

  $fullHtml .= MagicPage->MagicSection?($id);

module

Create a new file name MagicPages?.pm

Paste in the following:

 #!/usr/bin/perl
 ###############################################################################
 #
 #  MagicPages.pm
 #
 #  Generated content for particular Wiki pages
 #
 # to add a new magic page, follow the template below at package Foobar
 
 {
   package MagicPage;
 
   our @registered;
   
   sub register {
     # borrowed from Mych's Wookee.pm - thanks Mych :-)
     # fills the @registered array with the names of the packages
 
     my $class = shift;  $class = (ref $class or $class);
 
     push @registered, $class
       unless grep /^\Q$class\E$/, @registered;
     }
   ############
 
   # call this from UseModWiki
   sub MagicSection {
     my $class   = shift;
     my $page    = shift; # the current wiki page
     my $text;
     
     # if one of our packages matches the name of the wiki page...
     if( grep /^\Q$page\E$/ , @registered ){
       # ... then ...
       # ... make an opener
       $text .= "<div class=\"magic\" id=\"$page\">\n";
       # (if you're not using CSS you might want to put an <HR> here )
       # ... run its script
       $text .= $page->GenerateContent;
       # ... make a closer
       $text .=  "</div>\n";
       }
     return $text;
   }
 }
 
 
 #############################################################
 #
 # page: Foobar
 # this is just a template
 {
   package Foobar;
   @ISA = qw(MagicPage);
   Foobar->register();
   ###########################
     
   sub GenerateContent {
     return "Generating... FooBar\n";  
     # put the script for the page here
   }
 }
 #############################
 1;


--------------------------------

Notes

I've already made changes to the above: there's no need (as far as I can tell) for OO, so

 MagicPage::register('Foobar');

works just as well.

My problem is what to do for something like

 MagicPage::register('Category*');

Register regexes. Match soft against regexes, not hard against string constants. That is, instead of

    if( grep /^\Q$page\E$/ , @registered ){

write

    if( grep { $page =~ /^$_$/ } @registered ) {

Note that this version doesn't quote metacharacters. This isn't a problem as we might assume the person controlling the script isn't out to hurt himself (intentionally; nothing said about accidentally). -- SunirShah

---

One day I think magic pages are the way to go because they simplify the namespace of the wiki. The next day I worry that making certain pages magical subverts MeatBall:OpenProcess. Both cases involve special cases, and special cases are confusing.

I admit that WantedPages? are probably a special case. Though I would question whether you have the Category* idea upside down. Do you really want to force your users to make each MeatBall:ReverseIndex a Category* or do you really just want to improve the facility of reverse indexing? Maybe what you want is an MeatBall:InternalTransclusion (an inclusion) of the search results or a macro a la MeatBall:MoinMoin or a combo box listing all the backlinks? -- SunirShah

I think in a way MagicPages enable Open Process. Consider this: at the moment, the Wanted Pages page on Meatball is closed. The explanation at the top of the page was hard-written by you into the script. No-one else can change it or MeatBall:IncreaseClarity. Making this a magic page brings the page into the wiki. Likewise the Image uploader we have on UnrealWiki. As for Category*, I'm thinking of certain wikis I have seen where the Category pages simply display the category search results below the editable text. It saves a click -- some Wiki hosts might want it, some might not. Admittedly, it encourages all reverse indexes to be named "Category". And it wouldn't be much use somewhere like MeatBall:BookShelved. -- tarquin. -- PS: Sunir, do you want to rewrite wanted pages to fit into this, or shall I?

You could just simply allow an inclusion from another page on site. e.g. [IncludedPage: ThisWiki:back=CategoryFoo] I'm tempted to make all the so called special pages work like that, e.g. [IncludedPage: ThisWiki:action=rc] At least that would make all the special functions actions, and then allow the users to figure out the best way to display them. Also, if done properly, an IncludedPage? feature might be quite nice. As for wanted pages, go ahead and rewrite it. It's only two lines! -- SunirShah

In that case it would be nice to refactor the actions code too... The good thing about this is the way a site owner can add a function by pasting in a script into one place -- no need to add an extra line to an if-block! -- tarquin

After a long hiatus looking for work that doesn't exist, I started working on 2.0 again last week. With 2.0, all you need to do is have a module with the name of the action. The relevant code is:

    my $handler = 'UseMod::' . ucfirst($Parameter{action}) . '::Do';
    eval { &$handler } or &ReportError($@);

I need to write some code to require the appropriate module if it isn't loaded, but that's a two-liner. -- SunirShah

Neat! I was going to do a module-per-magicpage, but I couldn't work out how to do what you've done above, so I resorted to package-per-magicpage. -- t

See WikiPatches/MagicContent