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?

AC

I just read TWikiSkins, and it is perfectly clear, AFAICT.

CC

Why would someone need a cover?

AC

cover allows you to push a new skin onto the skin path without overwriting personal or web specific settings that have been set using SKIN. For example, ?cover=kupu allows us to add the edit.kupu.tmpl without assuming what next skin on the path is. If we didn't have cover, the only choice would be to set ?skin=kupu - which would blow away the value of SKIN.

There are many, many places where cover might be used, but I felt that it was such an obvious concept that a lot of examples would only clutter the documentation.

CC

So I guess the answer to Arthurs question - "Can COVER selectively override template parts?" - would be a "yes"?

-- SP

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. ?cover=fred. It was never intended to be used by defining the COVER 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, SKIN, that could be defined to be the name of a single skin * A URL parameter, ?skin, that could be used to completely replace the setting of SKIN 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 ?skin) path
• 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".

CC

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

-- SD

---

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.

-- AJA

*sigh* 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 SKIN=two to get it picked up? And if view.two.tmpl didn't exist, it would fall back to the default view.tmpl? Well, now you can set SKIN=two,three and if view.two.tmpl doesn't exist, it will pick up view.three.tmpl, and if view.three.tmpl doesn't exist it will pick up view.tmpl, same as before. And if you Set COVER=one, it will looks for view.one.tmpl, then view.two.tmpl, then view.three.tmpl, then view.tmpl. Like it says in the documentation.

Steffen, as I said above, don't use COVER that way. If you want to set a per-user, per web or per-topic skin, then set SKIN. Covers are for temporary, short-term overrides. Wysiwyg uses the URL ?cover= parameter to add the kupu skin to the skin path for editing, without affecting the underlying SKIN.

CC

---

OK, CC 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 view.tmpl immediately.

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!

-- AJA

Item602 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://mail.twiki.org/do/view/Bugs/WebHome?cover=text

While you can achieve the same thing with ?skin, the use of ?cover 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

CC