[pmwiki-users] Greedy targets= with trails?
Martin Fick
fick at fgm.com
Mon Nov 21 10:47:01 CST 2005
On Mon, Nov 21, 2005 at 10:25:58AM -0600, Patrick R. Michaud wrote:
> 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.
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?
> 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.
Oh, I didn't realize this was already discussed, sorry.
> 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.
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?
> 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.
-Martin
More information about the pmwiki-users
mailing list