[pmwiki-users] Greedy targets= with trails?

Patrick R. Michaud pmichaud at pobox.com
Mon Nov 21 10:57:31 CST 2005


On Mon, Nov 21, 2005 at 11:47:01AM -0500, Martin Fick wrote:
> > Well, while the pagestore could potentially extract the title
> > without too much expense, having pagestore figure out the
> > targets= attribute would be *very* expensive and would affect
> > the whole system.  
> 
> Hmm, are you suggesting that this would be expensive for
> other reasons than pagelists?  It seems like it would be a
> vary small hit for evey page load unless a page were
> extremely larege in which case the hit would not seem
> unusual would it?

At the moment, the only way to somewhat reliably figure 
out all of a page's targets is to render the page through 
MarkupToHTML (this is what the edit routine does when saving
the page).  That's fairly expensive to incur on every page
read.

It's possible that we could come up with optimizations to
MarkupToHTML to be able to let rules specify when they
need to be activated and when they can be skipped, but
it's still a lot of overhead to attach to every page read.

> I don't see this as a problem since I would consider having a 
> trail on page similar to having an include on page, while it
> might be nice, pmwikie doesn't save links on included pages does
> it?

No, PmWiki doesn't consider links in (:included:) pages to be
targeted from the current page.  I hadn't decided yet if
trail links should be treated like included pages or not.

> > Another approach would be that updating a
> > trail causes the targets= links for all pages on the trail
> > to be automatically recalculated.
> 
> I think that this solution would be rather difficult to manage.

Oh, it's not pretty but it could be done without too much
trouble.  It's just another custom function in the edit+save
sequence-- all it would have to do is ReadTrail on the current
page and then go through and update the targets= for each page
in the trail.

Pm




More information about the pmwiki-users mailing list