[pmwiki-users] Suggestion for a Page object

Martin Fick fick at fgm.com
Fri Apr 8 17:50:00 CDT 2005


On Fri, Apr 08, 2005 at 04:18:29PM -0500, Patrick R. Michaud wrote:
> 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.  

  Yes, I figured that would be your reasoning here. :) An
array is much simpler.


> 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).

I'm not sure what you mean by 'virtual' methods?


...

> 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.

  Yes, I was thinking that too.  Would obscuring pagefile
inside of a Page object not correct this?  i.e. any
functions needing access to the page date would go through
Page and not even know that it's in a file, it could be in
a DB.

> 
> 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.

  Actually, I'm not sure why your modification did not
provide that much of an improvement, but if you remember
the realNames hack I sent, it did better.  This provides a
similar improvement as my ugly hack.

  But yes, glad to see the change.  Another simple idea I 
realized could have been to simply index the returned 
pagelist by the pagefile and use the key in for loops to get
the pagefile without doing a lookup.  This incidentally
would probably also allow you to eliminate the 
unique_array() call in ListPages I think.  This might be
simple, but it does expose the pagefile, not what we really
want in the long run.

  My main reason for this suggestion was not to solve this
problem though, I just noticed that it could apply here as
well since I have been so focused on this issue lately. I
was suggesting it mainly to make it easier to expand the 
functionality of pagelist...more below




> >   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
> or
>     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.


  That would be very nice. It would be good to be able to
load things on demand, even the 'text'.  A while ago we
talked about being able to include sections of pages in the
pagelist, this would be very usefull here.  Loading the
text for all pages in FmtPgeList, regardless of whether it 
is needed or not, would not be a good thing.  This would 
be a good place to use the unset($PCache) after each page 
was printed without drastically limiting the amount of 
pages we are able to print.


  This part right here is the 'evil' part that I'm trying 
to avoid in FmtPageList():

    $matches[] = array(
      'pagename' => $pagefile,
      'size' => strlen(@$page['text']),
      'author' => @$page['author'],
      'time' => $page['time']);
  }


  If I want extra attributes in a formatting function, I
either  have to add them all here which is bad because they
may not be  needed in other formatting functions, or, this
function could get littered with nasty ifs determining
whether an attribute is preloaded or not.  I will look to
see if the PCache mechanism  can serve this purpose.


> 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.

  Reacting to memory constraints would be hard, but I think
we could probably easily keep track of the size of files
cached and allow reasonable limits to be set.


> 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.

  Nice,

  Have a good weekend,

  -Martin




More information about the pmwiki-users mailing list