[pmwiki-users] Greedy targets= with trails?

[Patrick R. Michaud]

On Mon, Nov 21, 2005 at 11:10:01AM -0500, Martin Fick wrote:
> On Sat, Nov 19, 2005 at 10:42:43AM -0600, Patrick R. Michaud wrote:
> > On Fri, Nov 18, 2005 at 07:06:07PM -0500, Martin Fick wrote:
> > >   I am using pmwiki2.0.0 and I noticed some strange behavior
> > > with the  targets= header index.
> > > 
> > 
> > It's possible to turn off target= information entirely, but 
> > this will disable the links= option and cause the refcount.php 
> > script to stop working.
> > 
> > > I would prefer to run my site without any duplicate meta
> > > data in the file headers. 
> > 
> > Does this mean you would also prefer that PmWiki not save the
> > title= attribute?  Technically that is "duplicate meta data" also,
> > and disabling it will cause title markups to work somewhat incorrectly.
> 
>   Yes, excpet that I want to eat my cake too and have the
> pmwiki internal know how to extract the title from a page
> without looking at a header.  It almost seems like the page
> meta data attributes should be something returned by the
> pagestore since they are effectively a caching mechanism. 

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.  

This is why we go ahead and figure out targets= once, when 
the page is saved, rather than doing it each time the page 
is loaded.

>   Despite my unusual desire for a slower system, :) it does
> seem to me that saving the prev and next links for trails is
> just begging for problems and wrong since there is no current
> update mechanism for this in pmwiki.  Do you think this is
> something you will fix?

Sure, it can be fixed -- until your message the prevailing 
opinion has been that having targets= be possibly incorrect 
in a few cases such as WikiTrails is an acceptable compromise 
in order to have faster page listings.  

There are two approaches that immediately come to mind -- one 
would be to say that the value for targets= doesn't include 
any trail links.  Another approach would be that updating a
trail causes the targets= links for all pages on the trail
to be automatically recalculated.

Pm