[pmwiki-users] Greedy targets= with trails?
Patrick R. Michaud
pmichaud at pobox.com
Mon Nov 21 10:25:58 CST 2005
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
> 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.
More information about the pmwiki-users