Re^9: Personalizing the linkers (happen)

. . ., but I dont really see how customized link types on a per user basis can be made to work, nor why they should be made to work.

I make a post that includes a foobar:// link. $reader comes along and wants to read it. The Everything Engine retrieves the text I wrote and post-processes it to generate HTML. It sees [foobar://abcd|ABCD]. The [] brackets say "Go look up a linker method". It does so, checking my personal linkers first. It sees the foobar:// definition and creates a href from it. EE then goes ahead and displays the HTML.

From $reader's perspective, he has no idea whether or not I did [http://foobar.com?q=abcd|ABCD] or [foobar://abcd|ABCD]. All $reader knows is that s/he can click on the link, be sent to the useful page at foobar.com, and be englightened.

From my perspective, since I link to foobar.com in over half my posts, my PM experience is improved. And, when I decide to improve how I like to foobar.com, I can change my definition and the EE will go ahead and change the href it generates (if my understand of the EE is correct).

This makes things like the change from www.perldoc.com to perldoc.perldrunks.org to perldoc.perl.org much easier to manage.

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?"

Comment on Re^9: Personalizing the linkers (happen) Select or Download Code

Replies are listed 'Best First'.
Re^10: Personalizing the linkers (happen) by demerphq (Chancellor) on May 06, 2005 at 19:46 UTC
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 Provide dynamic links for site purposes. This includes things like the pmdev:// and id:// links, which can't really be done any other way. Provide an easy way to do "classed links" for things like searches and lookups, examples being dict:// and jargon:// and cpan:// links. 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	[reply]
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?"	[reply]
Re^12: Personalizing the linkers (happen) by demerphq (Chancellor) on May 06, 2005 at 20:34 UTC
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	[reply]