Implementing link proposals

TODO

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