Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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 ;-}

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://528380]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-04-19 06:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found