[pmwiki-users] Suggestion for a Page object

Patrick R. Michaud pmichaud at pobox.com
Fri Apr 8 16:18:29 CDT 2005

On Fri, Apr 08, 2005 at 04:16:42PM -0400, Martin Fick wrote:
> Pm,
> What do you think about adding a class along the lines of this:
> [...]

In general I think it's a good idea, but thus far I've avoided
doing much with classes/objects because it substantially raises the 
level of programming ability that one would need in order to be
able to work with it.  I only went with classes for PageStore
objects because I needed the virtual method capabilities that
were there (which I don't think I need yet for pages).

But this isn't to say it's not a good idea, or that we won't
eventually do it.  The get($prop) method you defined is
likely better as being an array entry -- somehow I think


is cleaner and more obvious than 


not to mention that we'd have to write corresponding


methods to get attributes *into* the page so we can write it.

On a related note, as part of improving the authorization functions 
I've already changed the WritePage function so $page arrays can store
"meta" attributes, where the attribute name begins with a '='.
Thus we could do:


where the '=pagefile' value is automatically set by ReadPage.
The various page-listing functions can then just cache the
filenames coming back and go with that.

Plus, the overall problem with something like 'pagefile'
(whether it's an entry in the array or a method) is that
it implicitly assumes a file-based storage format, which
goes against one of the big reasons for having implemented
PageStore in the first place.

The load on demand feature is nice, however.   And I think
that maybe you're placing too much weight on avoiding the
FmtPageName() function; as the code I sent you earlier shows,
avoiding it only results in a minor speed improvement.

>   The idea being to help make attributes load on demand. 
> This class would help ease the feature enhancement of
> pagelists.  It would allow the various formatting functions
> to display extra information about pages not already
> gathered in FmtPageList.  

PCache() already handles the grabbing extra information
about pages and caching it somewhere that FmtPageList and
other functions can easily get to, so I'll probably
stick with that.  (More to the point, PCache *doesn't*
cache things that eats up lots of memory, like the markup
text or page history.)  

It may be that we just need a PCacheGet($pagename, $attr) 
function that looks up $attr in the cache (and loads the 
page into the cache if it hasn't already been loaded).
Expiring things out of PCache is simple, just do
    unset($PCache[$pagename]);    # expire a page
    unset($PCache);               # expire the whole cache

although we can certainly provide functions to do this as well,
or turn the PCache into an object with methods.

Unfortunately, PHP doesn't reliably provide a function that
lets the script determine how much memory it's using, or how
much is left, so cleaning the cache when more memory is
needed may be a bit tough.

I'll keep it under advisement.  Earlier today I was playing with
ideas for other ways to implement categories (based somewhat
on some of Radu's suggestions) and I think they may sidestep 
the issue altogether.


More information about the pmwiki-users mailing list