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

My idea was a link to another search engine with the "right" search parameters. Maybe some code will clear this up : 

  my $userlink = "[CPAN:File::Find]";
  # or alternatively
  my $userlink = "[RFC:2068]";

  ...

  if ($userlink =~ /^\[CPAN:(.*?)]$/) {
    $HTMLlink = "<A href=\"http://search.cpan.org/search?mode=module&q
+uery=$1\">$1</A>";
  };
  if ($userlink =~ /^\[RFC:(.*?)]$/) {
    $HTMLlink = "<A href=\"http://www.rfc-editor.org/cgi-bin/rfcsearch
+.pl? ... $1\">RFC $1</A>"; # I'm not sure if
    # RFCsearch will work with a link or if it wants
    # a form ...
  };

[download]
So we would have "smart" outside links that send the user directly to an external search engine.

This would mean, that the user always gets sent to what that search engine thinks is current, which can be good or bad, but thinking how often I get sent to the Not found page and have to do the second click on "Maybe you want to ask CPAN", I think it would be a good idea to save that click ...

Replies are listed 'Best First'.
RE: RE: RE: Direct links to module documentation
by mdillon (Priest) on Jun 04, 2000 at 05:06 UTC
    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+)*))$/ ).

[reply]

      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

      [download]
      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.

[reply]
[d/l]

In Section Perl Monks Discussion