in reply to Re^9: Personalizing the linkers (happen)
in thread Personalizing the linkers

Ok, I now get what you want, and while hypothetically its doable I have to admit it makes me cringe. What you are saying is that while rendering a page for every node on that page we have to load the authors link options when we render it. For a big thread that could be many authors, even assuming most have no such setting its a lot of work however you look at it.

I seem to think about this linking mechanism differently to you. To me they are ways to

for these tasks IMO it makes no sense for you to be able to foist your own interpretation of these links on me. It does however make sense for you to be able to change the way those links look to you. For instance it may be that you have a subscription to some dictionary that is superior to which free one we happen to be linking to at the time, and it seems reasonable that you might want to use the one you have paid for instead. Likewise if you want cpan:// links to point at some alternate resource there is no reason not to.

But I dont think that you should be able to change the way those links look to me, at least not through this type of mechanism, as its perfectly easy for you to just link directly as appropriate. An example of this is id:// links and named node links. Part of the point of such links is that regardless of which url you are looking at the site and which node is linked you end up in the right place (and thus not logged out) when you follow the links. Forcing your interpretation of such a link on me totally defeats the purpose, you might have well just hardlinked with an A tag. Likewise for the cpan:// tags or similar types, why should you be able to decide what dictionary I visit? Or rather whats the point of doing via a dynamic link? Saving a few chars when typing?

I can see some benefit in coming up with a template system for what you see, but i dont see the benefit of the other way round, especially given the relative costs of the two.

---
$world=~s/war/peace/g

  • Comment on Re^10: Personalizing the linkers (happen)

Replies are listed 'Best First'.
Re^11: Personalizing the linkers (happen)
by dragonchild (Archbishop) on May 06, 2005 at 19:54 UTC
    I don't know the EE very well, so I probably mispoke. Whenever you determine what the linker method resolves to, instead of hard-coding the resolution, instead go to the $AUTHOR's definitions, then the $DEFAULT definitions. Whether it's on node-create or node-view doesn't much matter to me.

    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

      It would be node view, and think what it implies. When you view a thread or a page like PMD every author needs a lookup. The "normal" way such information is stored is in your users settings which pmdevers will often call $VARS. These settings are a stringified hash of all of your settings and are stored in the 'settings' table. So assuming we use the settings for this information we need to fetch it out and then parse it for the correct key. If we dont use the settings then we still need an extra per node fetch for each node we display. Thats a fair cost. On top of all of this we need to make sure that $AUTHOR is set correctly whenever the parsing code is called. This is not currently complete. What im trying to say is that this is a big load for what I think is minimal gain for the site.

      The opposite case however is much lower load, and IMO actually useful. Whenever a page is rendered in PM the users vars are automatically parsed out, and preloaded into the $VARS variable. This variable is always available when links are parsed so its easy and low cost to find out the users link mappings. I think a templating system with sufficient builtin patterns should suffice, and it doesnt require that much code to do, at least not in comparison to what you have in mind.

      ---
      $world=~s/war/peace/g