• Do not
register here on develop.twiki.org, login with your twiki.org account.
• Use Item7848
for generic doc work
for TWiki-6.1.1. Use Item7851
for doc work on extensions
that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
• Does this site look broken?. Use the LitterTray web for test cases.
This arised from a discussion on IRC, and it turns out noone has a clear idea what COVER actually does. What is the difference between COVER and SKIN? Can COVER selectively override template parts?
I just read TWikiSkins
, and it is perfectly clear, AFAICT.
would someone need a cover?
allows you to push a new skin onto the skin path without overwriting personal or web specific settings that have been set using
. For example,
allows us to add the
assuming what next skin on the path is. If we didn't have
, the only choice would be to set
- which would blow away the value of
There are many, many places where
might be used, but I felt that it was such an obvious concept that a lot of examples would only clutter the documentation.
So I guess the answer to Arthurs question - "Can COVER selectively override template parts?" - would be a "yes"?
It's dawning on me that it's not COVER that you don't understand, it's the concept of skin paths. COVER is simply a way to push extra skins onto the skin path, temporarily.
I'll try and explain this more clearly.
It might be easier to think of skins as being like directories
. Most people are aware of the concept of a directory path
, where a sequence of directories can be defined, so that if a file isn't found in the first directory, then the second directory is searched and so on. The skin path is just like that. If a template file isn't found for the first skin on the skin path, then the second skin is searched and so on until the template file is found. Now, the skin path is defined statically as a TWiki variable, called SKIN.
Unfortunately it isn't possible to define a TWiki variable in terms of itself, so something like
* Set SKIN = fred,%SKIN%
will not work. So, to allow for more flexible definition of the skin path we have the concept of a cover
, which is like an extra layer on top of the SKIN. It was intended to allow you to extend the skin path for the duration of a single URL - e.g.
. It was never intended to be used by defining the
TWiki variable - I only added that for symmetry and flexibility.
I described the rules for how SKIN and COVER and ?skin and ?cover are used to build up the final skin path that is used in finding template files.
In summary, Cairo had this:
* A single TWiki variable,
, that could be defined to be the name of a single skin
* A URL parameter,
, that could be used to completely replace the setting of
TWiki-4.0.0 has this:
- A TWiki variable,
SKIN, that defines the skin path
- A URL parameter,
?skin, that can be used to wipe out the setting of SKIN
- An independent TWiki variable, COVER, that can be used to completely replace the SKIN (or
- A URL parameter,
?cover, that can be used to completely replace the setting of COVER
So, in answer to the question "Can COVER selectively override template parts?" that answer is "Yes, but that's only the tip of the iceberg".
I've not read the above yet - i just need to add that when I set COVER to override the pattern skin, it stops Wysiwyg from working, which suggests to me that there is something suboptimal going on
Clear as mud, [[CC], clear as mud.
What I do know is that If I create a skin - AntonSkin - that only has a dot-tmpl file for "view" but which is fully functional in that it has links for "edit", "more" and so forth, then those functions will be picked up by the default skin-with-no-name
So in effect is this like COVER?
What still "muddy: is the order. Is it left to right? If I set the skin to AntonSkin does that really mean somthing akin to "AntonSkin,''" in COVER terms?
And if that's just the tip of the iseberg, what is the 90% of the iceberg hiding in the - muddy - water?
Please, you're managing to make this obscure and difficult. It may be obvious to you, CC
, but the fact that we're asking this question means its not the rest of us. Those "obvious" examples are clearly needed.
obscure and difficult it ain't.
OK, you recall how in Cairo that you could create a template file e.g. view.two.tmpl, and set
to get it picked up? And if
didn't exist, it would fall back to the default
? Well, now you can set SKIN=two,three and if
doesn't exist, it will pick up
, and if
doesn't exist it will pick up
, same as before. And if you
, it will looks for
. Like it says in the documentation.
Steffen, as I said above, don't use
that way. If you want to set a per-user, per web or per-topic skin, then set
. Covers are for temporary, short-term overrides. Wysiwyg uses the URL ?cover= parameter to add the
skin to the skin path for editing, without affecting the underlying SKIN.
you've illustrated a simple case that seems useful when developing a skin or if you don't valua a consistent look-and-feel and want to work with an incomplete skin. But as you illustrate, all its really done is stretched out the fallback sequence we had already - instead of falling back to
You've also shown how you
use COVER internally for Wysiwyg. Fine. But you said that the fallback sequence thet COVER extends was just the tip of the iceberg. I can see using the SKIN sequence for robustness in a development environment - in a production environment distrupting the cosnsitent look-and-feel would upset users and bring complaints, so you better do your skins properly - but I cant see this 'iceberg' of use for COVER.
In fact I can't see a use for COVER. Oh, I can understand why you need the mechanism internally for Whysiwyg, but as a generic high level tool?
Please, show us some that iceberg!
suggest one; a common "print" template that can be used with multiple skins, instead of having to have a different one for every skin.
Another example would be where you want to send a URL for your weekly report to a PHB. Try it: https://develop.twiki.org/do/view/Bugs/WebHome?cover=text
While you can achieve the same thing with
, the use of
lets you keep any extra furniture added by plugins that are sensitive to the underlying skin.
As I said above, I supported COVER for consistency. But I can see it being used as well; for example, a frozen topic can include * Set COVER = frozen
COVER documentation not so clear
Fri, 27 Jan 2006 build 8562
No Action Required
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback