Tarquin/Lunatic UseMooWookee Project

Rough notes for the class structure

• Page
  • PageWiki: pages that open a page from the server
    • Edit
      • Edit Conflict
    • Diff
    • History
    • PageWikiSpecial
      • RecentChanges (maybe this & below given a base class, SpecialPage)
      • Search
      • Wanted Pages
      • RandomPage
      • Image Upload
  • Preferences
  • Login
  • List all pages
  • Admin-Only
    • Rename
    • Ban IP
    • Lock / unlock site
    • Lock / Unlock page

I had an idea to isolate behaviour for diff, edit, conflict, history in subclasses. The problem is that PageWikiSpecial children need that behavour too.

Possible soilution: treat SpecialPages as a seperate tree of plug-in behaviours. (like bot brains).

Aside: can a class's parent be set at runtime? I suppose it can, since it's just

   our @ISA = Block;

which sets parentage. Nothing stopping a

 if( pants ) {
  our @ISA = Block; }
 else {
  our @ISA = NotBlock;}

and thus

1. indentify requirement as Browse, Edit, Diff, Etc
2. determine if SpecialPage
3. spawn object of (desired SpecialPage) as child of requirement in 1

Would that count as REALLY twisted though?

Mychaeel: It can be done and is even documented as doable (in that the method inheritance namespace cache is documented to be cleared when it's done), but it's a last resort at most... if you can avoid stuff like that, do it.

Tarquin: Doh! Diff & Edit etc dont need to load in the generated content... just the saved wiki text. So if the object is if class "Diff" (say), then the fact that it doesnt load the generated behaviour is irrelevant!

Admin Pages

Maybe make a base class for Admin-only pages. Hmm. maybe not, a simple Admin-only flag somewhere.

http://c2.com/cgi/wiki?ShallowHierarchies Let's have a class PageAdmin which handles checking the viewer's admin status & displaying a message.

Home Page

slightly special because no page specified means go here... so not a class, but a special case in PageWiki

Actually, might as well make it a special case at the class level. The class for HomePage could be as simple as reading a config variable for which page to open.

Diff & History

not sure how to handle diff & history. probably:

• Page
  • PageWiki
    • History
    • Diff

The really clever thing to do would be to have History, Diff and EditConflict create a new PageWiki object that handles opening the second page.

This business that new() is non-special means that a class can have several creation functions, I suppose.

Mychaeel: Absolutely. (Naming convention is C++-like, by the way – start class names with capital letters, method names with lowercase letters. You can structure either by using capital letters inbetween.)

That means page classes could have a NewPage() and a NewNested() (or whatever. names subject to improvement). If a nested page is needed for diff, history, edit conflict, etc, create a new instance of PageWiki, but the NewNested obviously doesn't need to make headers, it just needs to open a file & display text.

Main function

Pondering two approaches:

method 1:

sub doBrowse {
  print &getHttpHeader();
  print &getHtmlHeader();
  print &getPageHeader();
  print &getDocumentText();
  # etc
}


method 2:

<uscript>
sub doBrowse {
  getHttpHeader();
  getHtmlHeader();
  getPageHeader();
  getDocumentText();
  # etc
}
# each function handles its own printing.

As I see it, the advantage of (2) is that I can choose whether to build up a $text and print in one go, or print pieces as it goes.

Mychaeel: I strongly suggest you build the entire page in memory first, then print it at once if appropriate. Just think of the Offline Wiki (plus, you can send a decent "Content-Length" HTTP header so browsers know in advance how much content to expect and can display working progress bars while loading).

New()

In wookee.pm, new() is only ever called with one argument. Therefore, is the second line in sub new() useful:

    my $owner = shift;

It's causing me problems as I'm calling new( %PageVariables ) and the first piece of the hash gets eaten by it. Do i risk death or disaster by removing it?

Mychaeel: At one place in Wookee, new() takes a reference to an object's "owner" (to propagate information about embedded links and headers up the block nesting hierarchy). That's not a Perl built-in, it's merely my own design.

---

Mychaeel: Moo? I like the name.

Tarquin:

ZxAnPhOrIaN: I like moo too.

---

  sub Browse {
    my $page          = ' ';
    # need to know:
    # URL params
    # User name and status
    
    my %browseParams  = ( page=>'Home', action=>'edit');
    
    # determine which class to set $page equal to...
    foreach $subclass ( @registered ) {
      $page = $subclass→ChildofPage($page, %browseParams );
      print "checking... $page\n";
      # Page
      ## PageAdminTask
      ## PageWiki
      ## PageLogin
      ## PagePreferences
    }
    print $page→GenerateContent();
    #print scalar @registered;
  }

hmm.... not ideal. I'm trying to think if there's ever a situation where different tasks might both want to perform, given the input, and one should take precedence. If not, might as well have classes return nothing unless they want to take on the task, and use some sort of a "while ..." construction instead of "foreach".