Skinning Plone 3
Getting a bit bored with the common complaints. This is a good thing.
It seems that every few months, we get a round of moans about skinning Plone 3. It's too hard. There are too many distinct technologies involved. The hard bits of the learning curve - Python, ZCML - come too early. Some things are a bit unstable (viewlet re-ordering, say).
Last week, we saw a great article by Catherine Williams at WebLion, which sparked some interesting debate, and responses from Daniel Nouri and others. There's some great discussion in the comments of these posts, too.
But all the same, it's rather boring to be having these debates again and again. You should all be really glad it's boring, though - it means that this point of view is generally accepted. We hear you! And it means that people are working on making it much, much better.
How did we get here?
Plone's current skinning store suffers from a fundamental conflation of two concepts that ought to be distinct: skinning (theming) and customisation. Zope 2, CMF and Zope 3 all have a lot of advanced ways to allow developers and integrators to customise virtually any aspect of the system. There's some overlap between the three that causes confusion (this is also well known and being worked on), but even if there wasn't, surgical customisation and visual theming are two different tasks, often performed by different types of people.
When Plone was small and didn't do much, then all its templates were quite easy to customise. Therefore, you could skin the site by simply overriding the various views and the main_template. However, the more bells and whistles that Plone gained, the more you had to understand what those things did, and how they were wired together, in order to change how they looked. Ouch!
WHat is being done?
"Simplification" is a big mantra for Plone 4. The core is getting smaller. Unused and unmaintaned code is being removed. More things are being made optional. The customisation story (particularly the schism between portal_skins type customisation and Zope 3 browser layer type customisation) is being unified: Hanno Schlichting, who's the Plone 4 release manager, has said on the record that he won't ship it with two competing customisation stories.
This will help, but it won't address the theming issue directly. Instead, we are talking about a few different approaches:
Tiles and layout
There is a proposal and prototype floating around that deals with how to improve Plone's ability to handle complex page layouts and composite pages. In a nutshell, a page of content will contain static HTML with references (in <a /> tags with a special 'rel' attribute) to dynamic components such as folder listings, polls, news headlines or anything else. The overall site layout will be managed as a similar static HTML document, and there will be a simple protocol (based on HTML tags and conventions) for merging the page into the site layout and overriding parts of the global layout on specific pages.
Under this proposal, tiles will basically unify portlets (which are stateful and administrator-configurable) and viewlets (which are not), and replace many instances where we've used content providers, viewlets or macros as a means of providing re-usable chunks of HTML. Writing a tile should be dead-simple: a basic tile will be nothing more than a template, and you'll only need to add Python or more configuration syntax if you actually need it. Creating a site layout will become an administrator's task; creating a "template" (in the MS Word sense) for page and site layouts will require nothing more than HTML skills.
There will still be a place for viewlets, but they will not be used as a generic means of componentising visual elements. Instead, they'll be used as, I suspect, was intended: a means for third-party product authors to "plug in" UI elements in pre-defined locations. The site layout will control where these locations are. You won't need to edit XML to place things where you want them.
Deliverance and branding
Tiles should solve the problem of how to get the dynamic elements you want into the page, and should give Plone a much more impressive GUI for page authors to control page layout.
There will also be a temptation to introduce branding/theming into the site layout (which, after all, is just HTML), and for simple sites that may indeed be appropriate. However, Plone 4 will also have some very cool new plumbing: WSGI:
WSGI, the Python Web Services Gateway Interface, allows you to build a simple "pipeline" of mini-applications that can respond to or alter a request or a response. A skinner won't need to know WSGI at all, but we'll probably ship Plone with a particular piece of WSGI "middleware" called Deliverance.
Deliverance is essentially a transform engine. You start with a template, which is literally a plain HTML file with related images and CSS, on the filesystem. This could come from a web designer with no knowledge of Python or Plone.
Then, you write some very simple CSS- or XPath-based rules that say things like "Plone has a <div /> with id #portal-personaltools. I'd like its contents to appear inside the second element in the <ul /> with id #page-actions". Deliverance will lift the content from Plone and shove it into the right place in the output page. Any content that's not included is not served.
I've used this approach in a project, and it's being used for the new plone.org design, due to launch shortly. It works very well, and allows a degree of separation between design and customisation that we've never managed to attain.
Deliverance, of course, works today. You can use it as a proxy that sits in front of any web application, not just Plone. People use this to get a unified look-and-feel across multiple applications. The new plone.org will have Trac and Plone looking like one using this approach. Check out the documentation if you're interested.