in reply to RE: RE: Direct links to module documentation
in thread Direct links to module documentation

what about editing a node? will the user editing the node see their original shortcut link, or will they see the expanded link?

if you can't easily edit these links afterward, then their value is not as great. on the other hand, i doubt that the expense of generating real links on-the-fly or storing two copies of the node text (source and expanded) are worth it either.

i think that having these sort of links go to a separate page that lists the full link and perhaps redirects after 5 to 10 seconds would be the most maintainable implementation.

that way, the author can simply edit the original text, the user will have a chance to see what resource their being sent to (and a chance to cancel), and it can be forward and backward compatible (as long as there's no links with titles matching /^(?:(RFC):(\d+)|(CPAN):(\w+(?:::\w+)*))$/ ).

  • Comment on RE: RE: RE: Direct links to module documentation

Replies are listed 'Best First'.
RE: RE: RE: RE: Direct links to module documentation
by Corion (Patriarch) on Jun 04, 2000 at 05:19 UTC

    The owner of the node would still see the original shortcut link - all conversion would be done when preparing the data for a HTTP request. The data for each node must be processed before sending it over HTTP anyway (all stuff in square brackets has to be redone as <A href=...>) and in this conversion loop, I would add the conversion of those "special" nodes. Maybe my imagination of how Perlmonks works is wrong :).

    Of course this would make some nodes more equal than other nodes, as no more nodes whose titles match for example

    /^(RFC|CPAN):(.*)/i
    could be created, which will confuse the user trying to create such a node. A totally static and within-the-system solution would maybe be the best and least painful solution.