[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