Skins are very useful for customized views depending on context; I propose a shortcut to set the skin with "aliases" to the view name, e.g. http://your.site/twiki/print/TWiki/TWikiDocumentation.

Pros:

1. cosmetic: ShorterURLs, easier to memorize, easier to send and spell
2. functional: some tools have limited InterWikis style functionality, by allowing only a prefix. Most notable example: the MeatBall:TouchGraphWikiBrowser (local: TouchGraph) - because of its poor page renderer, it badly needs a special skin, but can only prefix the URL path, not append the skin parameter

Cons:

1. Jargon:feature-creep?
2. 2 more lines of code ...
3. On Windows, symlinks are not available; you would have to copy, which is dangerous

Usage:

1. patch view, see the 2 lines diff to AthensRelease below
2. Create aliases: for skin in print plain pdf touchgraph... ; do ln -s view $skin; done
3. replace view in the URL with the skin name; this overrides the ?skin=name parameter plus the preferences.

-- PeterKlausner 28.Aug.2002

Interesting idea. Simplifies telling URL into phone a little. I like it, but:

• Skin name might clash with action name. Ie. somebody might define skin "edit", clashed with script bin/edit , unless scripts are *.cgi or so.
• Bigger issue for me is, that if I follow link with ie. "plain" skin from outside, first time view will render page with "plain" skin, but if I follow any link from the page, web's (zone's) default skin will be used. This change of skin is unexpected by user and IMHO will be rather confusing. I have no idea for any workaround.

-- PeterMasiar - 29 Aug 2002

Ad clash: you still could name a skin edit or whatever, you just cannot use that as alias for view.

Ad keeping skin: yes, this is confusing, exactly the same way as with the ?skin=xyz parameter. Not even changing the base tag in the skin does fix it. WhyBaseTag? And when will RelativeURLs work?
On the other hand: this behaviour is actually useful for the printable skin, and for a TouchGraph skin.

-- PeterKlausner - 30 Aug 2002

This patch is not compatible with the CacheAddOn: the first skin used will determine the cache content, as described in CachedResponses. I work around this problem with a separate script name setskin:

#!/bin/sh
skin=`basename "$0"`

if [ -n "$QUERY_STRING" ]
then                    QUERY_STRING="$QUERY_STRING&skin=$skin"
else                    QUERY_STRING="skin=$skin"
fi
export QUERY_STRING

exec ./view "$@"

The link the skin names to this script instead of to view. For keeping the skin, the best fix would be a viewurl() function as requested in ShorterURLs and NeedFunctionForScriptUrls.

-- PeterKlausner - 16 Jan 2003