Implementing link proposals


  1. Add performance testing of Foswiki::Render existing link handling so we can track how much we slow things down.
  2. I tried to make a nice AddFoswikiFuncWikifyWebTopicName, but it turned into Foswiki::Func::normalizeLinkString, which wanted to return a Foswiki::Address or Foswiki::Address::Link or Foswiki::Link::FoswikiAddress or something inheriting from CPAN:URI
  3. So, the goal is to make a generic link parser that will return these different types of objects.
    1. It should be that all link forms understood by Foswiki::Address are usable in [[bracketed links]].
    2. It should be that InterwikiPlugin and SemanticLinksPlugin can hook in and claim their own link syntax (and return their own link objects)
    3. It should be that the %URL{}% and friends suggested in EnableCloudStorageForAttachments and DeprecateContextlessURLConstructs can leverage this work.
    4. It should be that TopicDisplayName is just a special case of the link decorator which I had been thinking should enable mangling of URLs as per EnableCloudStorageForAttachments, but why not mangle the link text too.
  4. Anyway, update Foswiki::Render to use the new OO way of parsing & generating links.
  5. Update WysiwygPlugin to leverage this work.
  6. Review performance.

-- PaulHarvey - 16 Dec 2011

One of the older proposals is TopicDisplayName. Major concern raised is (foreseen) performance degradation. But with a different store implementation that might be less problematic.

-- ArthurClemens - 16 Dec 2011

Excellent! Added to the list.

-- PaulHarvey - 16 Dec 2011
Topic revision: r4 - 03 Jan 2012, RichMorin - This page was cached on 02 Mar 2021 - 12:07.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy