Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: in monktitlebar, link to sections by id?

by Tanktalus (Canon)
on Feb 07, 2006 at 00:46 UTC ( [id://528380] : note . print w/replies, xml ) Need Help??

in reply to in monktitlebar, link to sections by id?

As was also pointed out, the monastery is based on both node ID numbers and names. Thus, whether you use [Super Search] or you use [id://3989], you'll get to the same node. The only times there is a difference are when either the name matches more than one node, or when the name doesn't completely match any node.

So I'm not seeing really any significant benefit in changing the title bar from names to IDs except to annoy the heck out of whoever has to write the change. ;-)

Theoretically, lookup by number could be faster for when they're clicked on. But good indices probably take care of that, more or less. And using names reduces lookups at rendering time - it takes no (database) effort to convert [Super Search] to "Super Search", but if you use [id://3989], then PM needs to do a lookup every time the node is rendered to provide the title. (Ok, so these ones have a good chance of always being in the cache.)

In fact, if we want to help reduce the rendering effort a bit, we should use the names exclusively - the number of times a link is rendered versus being clicked on must favour this method.

To that end, I would propose a couple of minor changes (heh heh):

  1. The code that does the node linking would stop doing lookups. Instead, the code that converts the URL-like links (id://, http://, etc.) would do the lookup if required (which I think is only id://). And it wouldn't do any lookup unless no title is given (via the pipe).
  2. The link created would have some sort of hidden attribute, say "alt", which would have the original text.
  3. holli's firefox plugin would use the alt tag if it's a perlmonks URL that is being clicked on rather than the href.

Or that seems to me like a reasonable way to help reduce the overhead.

Now, to take the opposing side of this idea for just a moment, I have two words for me: "Premature optimisation!" Unless someone thinks we're using up too much CPU time with this, and thinks that such a plan could possibly have a significant enough effect to warrant the effort, it's not really worth doing.

Which means, now that I'm near finished, that I don't think a change of any type is really warranted ;-}