Implementing link proposals

Gathering thoughts before tackling a re-work of link handling in Foswiki

• AddFoswikiFuncWikifyWebTopicName (Tasks.Item11356)
• LoadDifferentTopicVersions
• TopicAddressing
• Tasks.Item11025 "Foswiki should be able to handle Anchor before URL param in the same calling URL"
• DeprecateContextlessURLConstructs
• EnableCloudStorageForAttachments
• SupportDynamicGeneratedAttachments
• TopicDisplayName
• SupportRelativeBracketedLinks

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