[triangle-zpug] "Thick" vs. "thin" skins

Chris Calloway cbc at unc.edu
Wed Dec 22 21:25:51 CET 2004


Jim Allman wrote:
> Just curious: Is it normal for skins in a system like Plone to include 
> not just appearance, but behavior?

Yes.

CSS. ZPT. Just about any Zope object is fair game for a skin.

That's why it's sort of semantically tricky to refer to a skin as either 
a folder, collection of folders, or a lines property listing to a folder 
search order.

> I'm struck by the breadth of its 
> skins--essentially, everything but document content seems to be provided 
> (or not) in the active skin.

You could even put content in a skin if you wanted to.

An example would be images. Lots of skins provide images. Buttons, 
icons, box borders, box headers, logos, banners, etc.. Images are 
content, just not text content.

To the extent that CSS allows you to supply images as attributes, there 
is some inherent lack of content/presentation separation in CSS itself. 
The idea in Plone is to rectify that by making attribute values which 
refer to content be Zope object properties. If you look through 
plone.css, you will find various references to DTML variables in the 
base_properties context. Example:

a {
text-decoration: none;
color: &dtml-linkColor;;
background-color: transparent;
}

So instead of setting the background color explicitly in the CSS, I set 
it in the base_properties properties tab through the ZMI. But color is 
presentation, not content. Here's an example from plone.css of 
separating content out of the CSS with a Zope object property of 
base_properties:

#portal-logo {
background: url(&dtml-portal_url;/&dtml-logoName;) no-repeat;
border: 0;
margin: 0.75em 0em 0.75em 1.5em;
padding: 0;
}

Here, the logo for your plone site is specified as a base_properties 
object property called logoName. That, my friend, is just too cool for 
words. Although I kinda don't like the way the Plone developers did that 
as a background image. I would have prefered DTML substitution of the 
src attribute in an <img> tag by means of CSS. There's a good example of 
that in plonePrint.css:

#content a:link:after,
#content a:visited:after {
content: " ( " attr(href) " ) ";
}

Here, whenever a Plone page is printed, the content of all links becomes 
the href attribute of the link. So pages print out with URLS in place of 
link text. Way beyond cool. *This is proper use of the "content" CSS 
property.* However, the content property in CSS belongs to the CSS2 
specification, and browser support for the content property in CSS is 
spotty. I guess that's why the Plone developers did what they did for 
the site logo. I might not matter so much if that substitution doesn't 
take place in the plonePrint.css. If the substitution doesn't occur, 
then the normal link text appears instead. And some people really hate 
the substitution of URLS for link text in printing, anyway. My project 
manager made me take it out the first time she printed a page from our site.

Note, you can use the properties of other object besides base_properties 
to configure skins. base_properties is only used because of the 
following statement in plone.css:

/* <dtml-with base_properties> (do not remove this :) */

You can have several sections in your ploneCustom.css referring to many 
different "property sheets" (Zope objects in which the main tab of 
interest is the properties tab. With clever DTML, you could 
automagically set which property sheets are active in a skin based on 
things like REQEUST variables.

> Now I understand why changing skins used to show (or hide) the calendar 
> portlet in Plone. It truly didn't exist (or wasn't include via macros?) 
> in one of the standard skins! Powerful, but kinda confusing.

Were those skins which did the change main_template nasty?

> Are there guidelines 
> or best practices on skin design, so that people can easily extend or 
> substitute skins without breaking things?

If there's not, there should be. :)

I did a search in the brand spanking new Plone Help Center (which we 
will be working to enhance at the Boot Camp Sprint) and this is what I 
found:

http://plone.org/documentation/tutorial/where-is-what/whereiswhat

Not exactly best practices, but definitely some guidelines.

Joel gave one of two presentations on *Plone* best practices at Plone2 
Conference. One thing I remember from that was *keep you skins on the 
filesystem* instead of as objects in the ZODB, and configure the skins 
with properties in the ZODB. This is another content/site separation issue:

http://plone.org/Members/pupq/best_practices

> (I suppose the sensible thing 
> would be to create "structural" layers, "functional" layers and 
> "style/asset" layers, then document some recommended combinations.)

Joel is in charge of, among other things, the Plone Documentation Team. 
If making such recommendations appeals to you, I think there will be 
opportunity at Boot Camp to become part of that team. The PDT just made 
the transition to Plone Help Center and ported hundreds of pieces of 
content over to it, but there's still overwhelming gobs of work to do.

It sounds to me like your recommendation is when making a skin for a 
product or a site, the skin should be separated into multiple layers 
(most current products only register one layer and add everything into 
that one layer). That could be a good thing. Or could lead to a 
proliferation of layers. The Plone base product obviously has done some 
of that separation already with folders like plone_styles, 
plone_templates, and plone_scripts.

Here are the standard out of the box Plone layers in the Plone default skin:

plone_ecmascript
plone_wysiwyg
plone_prefs
plone_portlets
plone_templates
plone_3rdParty/CMFTopic
plone_styles
plone_form_scripts
plone_scripts
plone_forms
plone_images
plone_content
cmf_legacy

That's a lot of separation going on.

Notice the plone_3rdParty layer. It seems to me that more products 
should be using the plone_3rdParty folder, creating a product subfolder 
in it, and registering the subfolder as a layer in default skin. I dunno 
if that is a best practice of not. Seems like it could be. Today I see 
products like zwiki creating their own layer folder, and other products 
adding skinning objects into other pre-existing layers. I assume some of 
this is going on because the products are Zope/CMF compatible, whether 
you have Plone installed or not.

It might be worth your while to check out a product called CPSSkins. It 
was made for Nuxeo CPS. But like most products made for Nuxeo, it works 
on Plone. Basically, it give you WYSIWIG control over the presentation 
of many plone site elements. I'd install it on TriZPUG, but it pretty 
much takes over your site with it's own default skin it calls a "theme" 
and it does some other things I'm not too fond of like adding theme 
controls to a plone site's public interface. But you can play with it 
without installing it by getting a free Plone site at:

http://www.objectis.org/

Objectis puts CPSSkins, and a whole bunch of other products, into the 
installable products list for each free Plone site.

-- 
Sincerely,

Chris Calloway
http://www.seacoos.org
office: 17-6 Venable Hall   phone: (919) 962-4323
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599




More information about the triangle-zpug mailing list