Feature Proposal: Add TWikiDocGraphics in Main Web

Motivation

Sites typically have some customized icons, especially those with TWikiApplications. Upgrading TWiki is easier if the user supplied images are separated from the TWiki system images.

This is consistent with TWiki.TWikiPreferences / Main.TWikiPreferences handling. It could be applied to other things as well, such as the custom templates of the CommentPlugin.

Description and Documentation

The Main.TWikiDocGraphics? (site topic) could complement the existing TWiki04x01.TWikiDocGraphics (system topic.)

• Site admins can attach doc graphics to the site topic in the Main web
• Calling %ICON{}% searches the icon first in the site topic, then in the system topic (that way it is possible to overload system images)
• Caching needs to be implemented for speed; cache refresh on topic save of system topic and site topic
• The installer should copy the topic only if it does not already exist

Examples

Impact and Available Solutions

Implementation

A caching algorithm is needed to deliver the icons quickly. LetICONCalculateImageSize also depends on caching, hence it makes sense to implement these two features together.

The cache contains records; each record contains info of an image:

• Name of image without suffix (e.g. rss-feed)
• Type of image (e.g. gif)
• Path to image file (e.g. /p/pub/TWiki/TWikiDocGraphics)
• Image width (e.g. 36)
• Image height (e.g. 14)
• Image description (e.g. RSS feed)

Caching works like this:

• For each ICON rendering:
  • For first ICON encountered on a topic view / topic rdiff:
    • Check if topic timestamp of TWiki.TWikiPreferences and Main.TWikiPreferences is newer than the cache file timestamp
      • If yes, refresh cache on disk and load into memory
      • Else, read cache from disk and load into memory
  • Render ICON based on cache in memory

-- Contributors: PeterThoeny

Discussion

I had this idea while working on a TWikiApplication for a client.

-- PeterThoeny - 11 Feb 2006

Using an arbitrary topic for icon attachments is already implemented in ICONTOPIC. Somehow that variable is not in the current TWikiVariables (Bugs:Item1631). But overloading is not yet written.

It would also be useful if icons from plugins could be overloaded this way. With a x number of plugins you get very different styles that are hard to control.

See also the related LetICONCalculateImageSize.

-- ArthurClemens - 11 Feb 2006

Yes, LetICONCalculateImageSize is related, and could be implemented as part of this change request.

I think the ICONTOPIC variable is a bit overkill, we removed the use because we merged the pattern skin graphics into the default image library. So, better to remove the ICONTOPIC variable.

Alternatively, we could introduce a new ICONTOPICSEARCHPATH where you can list a number of icon topics to search for icons. But this sounds also like a bit overkill.

-- PeterThoeny - 11 Feb 2006

Thinking this further, for Plugins it is useful to introduce a DOCGRAPHICSSEARCHPATH setting. For example, the RenderListPlugin has icons that could be used elsewhere, and the Plugin could make use of system icons and site icons. The question is performance, a cache expire test needs to be done on several topics instead of just two.

The ICON variable could be enhanced with a format parameter that expands tokens $name, $type, $file, $path, $description, $width, $height, $icon, $iconurl, $iconurlpath. For example, tokens for /path/to/somefile.doc are doc, gif, doc.gif, /p/pub/TWiki/TWikiDocGraphics, Microsoft Word file, 16, 16, full img tag, http://twiki.org/p/pub/TWiki/TWikiDocGraphics/doc.gif, /p/pub/TWiki/TWikiDocGraphics/doc.gif, respectively. Useful to construct a custom format, such as %ICON{ "%URLPARAM{type}%" format="$icon $type is a $description file" }% that renders as: doc is a Microsoft Word file.

-- PeterThoeny - 11 Feb 2006

Ping. This came up in Support.AllowICONsInWebPreferences.

-- PeterThoeny - 29 Nov 2006

Good idea. We could easily use the code from the template search path to create other search paths. Whatever we do, it should be consistent, so that users need to learn only one search path scheme. (I assume that this is not a 4.1 action?)

The other idea in this topic is to migrate the Main topic into a site customization web, and have the system configuration in the TWiki web. Let's look through what else is in Main and start moving into that direction.

-- ThomasWeigert - 29 Nov 2006

With yet another thing to search for - how about performance?

It can only be negative. It this worth it? Maybe it would be better to have a static alternative you can define in configure which would not cause further slowdown of an already too slow TWiki.

-- KennethLavrsen - 29 Nov 2006

Yes, it needs to be done with performance in mind, as I noted above. It can be done with intelligent caching (on search path and on icons attached to topics in search path).

Having said that, we can do things step by step: First simply support a TWiki.TWikiDocGraphics and Main.TWikiDocGraphics? (with caching), then add a search path later (if inclined).

-- PeterThoeny - 30 Nov 2006