I'm being sarcastic, I know, but I can't find any documentation of this feature. If you have a skin name that starts with the string "text" then it gets special hard-coded treatment. Specifically, when used alongside raw=on, it can be used to give you a text/plain rendering of the topic. Of course it's not that simple, you have to use a URL like this:

http://twiki.org/cgi-bin/view/Codev/WhyShowRawInATextBox?skin=text&contenttype=text/plain&raw=on

Magic.

So, what's wrong with this approach? Well,

1. It's a hack.
2. The first poor slob who innocently calls their skin "texture_skin" is going to get a shock. Not immediately, of course....
3. It's a hack.
4. It could have been done much more cleanly using "raw=text", whcih could have handled both the content type default and the raw mode.
5. It's a hack.

A strong candidate for refactoring, methinks. Unless there's some really strong, logical reason for doing it this way that I can't fathom.

-- CrawfordCurrie - 05 Oct 2004

I hate hacks.

-- MartinCleaver - 05 Oct 2004

It's in UsingTopicToDefineCSS. I prefer the clean version...

-- ArthurClemens - 05 Oct 2004

Yeah, it's a hack. Yes, I wrote it.

Usually the content type would also be specified in the url parameters so that it could be delivered as css, javascript etc.

The problem with it is that browsers don't cache the pages because of the url parameters.

What I'd realy like to do is have a mime script in bin that would either look at form settings or allow you to specify a false extension for the topic (e.g. http://twiki.org/cgi-bin/mime/Codev/SpecialSecretSkinNames.css)

It would then look at a TWiki.MimeTypes topic that would have a table of accepted form field names, i.e. MimeType or PageType and their values with corresponding mime types, or extensions and mime types.

Not sure what it should do if there's no match, maybe just default to text/plain.

I'm not sure which approach I favor most.

-- SamHasler - 05 Oct 2004

Erm; if you are rendering the plain text of the topic, surely the typical application is to make use of that text in a non-browser app? So why do you care if the browser caches or not? And why do parameters stop the browser cacheing these pages anyway? They don't stop it anywhere else.

The problem with the .extension syntax is that . is already used as a web separator. Of course the code could untangle this, but it seems easier just to use ?raw=text.

-- CrawfordCurrie - 14 Oct 2004

When UsingTopicToDefineCSS browsers don't appear to cache the pages due to the url parameters. We were seeing 5 hits to the view script for every page request until we made the css static files.

-- SamHasler - 14 Oct 2004