If memory serves me right, CC
implemented the ability to have multiple skins for a topic. This was to be leveraged with internationalization, for example.
However, I think we do not have (at least not documented) a mechanism of adding a skin to the current skin so that it does effectively "Set SKIN = myskin1, myskin2". An example use case would be to add in a topic a skin to the existing skin which makes minor modifications to the existing skin (e.g., wipe out the topic actions). --TW
P.S. I thought I had already submitted this issue, but could not find it. Please excuse the duplicate, if it was in fact submitted already.
If I understand what you mean, yes we do. The
parameter allows redefinition of the skin path. The
parameter allows stacking skins on top of the existing skin path. Example:
permanently redefines the whole skin path
pushes print.pattern to the head of the existing skin path.
Is it possible to write
Set SKIN = print.pattern,pattern
Set COVER = print.pattern
? -- AC
Yes, and yes.
But the variable
does not lead to the same effect as passing
as url param. -- AC
- Set COVER = print.pattern
As you can see from the above,
does not have any effect when used as a variable. I believe it needs to work just as
does... -- TW
The decision not to support
as a variable was quite deliberate. I didn't want to open another can of worms. Consider this use case:
1. A topic, A, includes topics B and C.
2. B defines COVER = B, and C defines COVER = C
3. You view A with cover=A in the URL.
what's the skin order? A,B,C,pattern? B,C,A,pattern? A,pattern?
It's easy to have a
variable because the value set in the topic replaces
any other setting, but COVER would have to be additive
, and I thought that was too complicated for little perceived benefit, so I made it URL only. if someone can show a killer app for it, then maybe a case can be made. --CC
I don't agree. If there is a case for adding a skin in the URL, there is an even bigger case for adding the skin in the topic. Here is an example: A user wants to modify the view mode in an application slightly (using topic-specific settings), e.g., by putting the form on top. This change of form location should apply to all skins, not just to a specific skin. So the user has to develop specific view templates for all skins and modify them accordingly. But what really should happen is that the skin is modified by overloading it with the local change. That would apply to any skin. (Really, the skin to use is a viewer choice, but the application appearance is not.) -- TW
Proposal is to add a COVER variable that parallels SKIN
- CC approve - low risk, and without it we just cause frustration
- LB approve - Stacking skins is one of the great features in Dakar adding flexibility to design. If low-risk, this proposal is logical extension for consistency.
- SD approve - consistency is really the most important thing to me
SVN 6856 CC