Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Skin in SitePublisher component
nirali
We we can have more than one skins to choose fro for a component. What exactly is meant by skin ? Is it just background look (font, color, border, size etc) , which is a part of Appearance XML ? OR is it Appearance XSL section, which picks up content from Content XML section and outlook attributes from Appearance XML section ? Are we creating more than one Appearance XSL section or more than one Appearance XML sectionn ?
If its more than one Appearance XML section, then why do we need that because end user can just change values by himself for Appearance XML section ?
Thanks
Find more posts tagged with
Comments
nipper
This is explained in the SP developers guide. You can try it quite easily and you will see different XSL for the skin.
IMHO, I am not a fan of using those, esp if there is medium to small differences in the XSL.
moulikk
We have been using those in a few scenarios.
1. Simple cases where the width of a simple textarea component can be set by the user to be narrow/medium/wide. We used skins strictly as a way to stick with easier feeling process for our non-technical authors.
2. We are using skins in one left navigation component which has some dynamic elements being populated at the bottom. This allows us to create a page template with the left navigation component on it and the user can select which flavor of left nav he wants... default, one with stock ticker at the bottom, one with "TeamSite Rocks" above.. whatever.
The problem is - sometimes mass component/page updates (in case you updated the component/page template) messes up the skin chosen and you have to regression test.
Rick Poulin
@moulikk
: The issue with the use cases you've mentioned is that they could be accomplished with a regular dropdown datum and your XSL would probably be a lot easier to manage.
In general, the skin field was meant for being able to render the same data in vastly different ways, where your xsl would otherwise just have an <xsl:choose> at the root and very few commonalities between the different cases. However in the real world, the number of times you wouldn't just make those different components is just about nil.
shameem
In my opinion,
For minor presentation deviation - having control at datum level and control them in XSL, provides goods customer experience.
Where as for major deviation in the presentation, skins will be preferrable with appropriate naming conventions of skins.