[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib Template.php,1.45,1.46 WikiPlugin.php,1.25,1.26

[Jeff D. <da...@da...>]

Hi Reini,

Now that I've started looking at PhpWiki code a bit again
(I hadn't really followed a lot of the changes for the past
few months)...   whew.... it's getting pretty messy.
(Not your fault, for the most part... :-) )

Anyhow,  I don't like <?plugin-head, and the extra hooks it
involves....   If something like it is really necessary, it
should probably be done via pagetypes rather than plugins.

Using plugins for RedirectTo is kludgy, but, I think, acceptable,
except for the extra hooks.

I've always planned on modifying the plugin API a bit, once
it became clear how it should be modified.  I don't think it
would a bad idea to modify the expandPI API so that a plugin
can get some information about the context from where it's called.
(That way RedirectTo can check that it's the first thing on
the page, and issue an error if it's not...)

Not sure how this should best be done.  I'm thinking: pass expandPI
a PluginContext object (or some such) instead of the current $request
second argument.  The PluginContext  will contain methods to access
things like:
  * pagename
  * input line number?
  * query POST/GET args directed at the plugin?
  * the $request
  What else?

I'm beginning to plan on cleaning up the PageType code now too,
as that is driving me nuts....

I think, at present the only other place plugin-head is used
is your FrameInclude plugin.   (Another plugin which scatters
hooks everywhere ... hmm...)

...err... random thoughts and rantings... on sunday .. before coffee...
  sorry I'm so grumpy...


Anyhow, I plan on trying out a Transclude plugin which will
use <iframe>s (or <layer>s for NS4 compat) which might obviate some of
the need for FrameInclude...



More random comments:
     Why UserPage/Preferences?  Why not just store the prefs in a
  'preferences' meta value  (which would be a hash) on the UserPage?  
  Actually, even better, why not just one meta-value called 'userpage'
  attached to the UserPage.  It would be a hash containing among other
  things:
     'preferences':  (another hash)
     'password':  (if password is stored in the UserPage)
     ....
  (This avoids namespace pollution of the meta-tags.) 
  (The presence of the 'userpage' meta tag marks the page as a user page.)


About subpages:

  /Page still looks like a absolute path to me.  (I think I still
  like the idea of dots instead of slashes --- but maybe that's
  just cause I'm an object orientated kind of guy....)

  Should /SubPage (which really means ThisPage/SubPage)
  really be displayed (when linkified) as "SubPage"?
  (I think the '/' should be preseved to indicate to the user
  that it's a subpage link.)

  Should ThisPage/SubPage (within page text) really be rendered
  as two links (with "ThisPage" linking to the parent and "SubPage"
  linking to the child?)    I think splitting the page title
  this way makes lots of sense --- it makes it easy to get to
  the parent page.  But splitting links within the
  page text this way, to me, just seems to add confusion without
  adding much utility...
  
  It would be nice to have a shorthand for referring to sibling
  subpages.  Any ideas?  '../SiblingPage' might work, but I don't
  like it.  which leads to...

  Shorthand for referring to the parent page?

Again, sorry I'm so grumpy this morning....