Login

Repoze Blog

2008-02-18 00:00:00-05:00

Plone Sitetheming Part 2: Why and What

Applying a high-quality design to Plone is more of a programming task than it should be. This proposal isolates the pure look-and-feel, site-global part into something called a "sitetheme" that tailors a radically simpler, re-usable facility for corporate ID.

Motivations

Why pursue this facility? Who is it aimed at and what issues do they have with the status quo?

In a nutshell, this proposal wants to make it radically simpler to brand Plone. The designer's "sitetheming" job will focus on saving HTML to disk. No templating, with weird macro decomposition and API calls. No resource registries. No buildout. No restart.

  1. People that produce high-quality designs won't want to learn Plone templating. Imagine if their HTML (and skills therein) was used, untouched.
  2. Reducing the amount of "unique-to-Plone" stuff that is important to getting started can help reduce fear-of-the-unknown and learning curve.
  3. Sometimes this design already exists and doesn't need to be "compiled" into ZPT/packages.
  4. Web designers probably don't want to run a Plone install to maintain the the branding.
  5. Theme resources, such as CSS and JS, will be served from the HTTP server directly.
  6. Focusing Plone on the semantic information unique to a single resource/URL will promote other goals such as integration.
  7. It is possible that performance improves, if less is done in ZPT and Zope.
  8. If Plone moves to a more Python-friendly (WSGI) philosophy, then theming non-Plone sites with the same artifacts is a benefit.

Again, just to be clear: the single biggest goal is to be kind to civilians.

Sitetheming in a nutshell

First, a point about nomenclature. Since theming was introduced as a Plone word that covers skinning, templating, and (to a degree) programming, this proposal temporarily chooses a new word. We will call this new facility "sitetheming" to disambiguate jargon skew. Perhaps at the end, we'll just call this "theming".

Most pages in a site share lots of common elements. Logo, site menu links, footer, links to CSS and JS, etc. This is usually referred to "branding", "look-and-feel", or "corporate identity". On larger projects, the people managing the branding have little desire to learn a new system. On smaller projects, with people just learning, they haven't mastered enough yet to make the pages "their own".

Sitetheming is a facility for imposing a common look-and-feel on most site pages using no templating. Instead, the designer or customizer maintains a pile of HTML/CSS/JS/PNG artifacts at some reachable location. The HTML is then used as an "overlay" on the content coming out of the site.

More specifically:

  1. Save some HTML and other stuff.
  2. Make a rule file that defines spots in the theme that need to be replaced. For example, the big block in the middle column.
  3. Later, as content is being served, blocks are pulled out of the content and merged into the theme.

This diagram shows the basic idea:

In this approach, HTML is the API. As long as the theme continues providing elements with the correct ID or class names, and as long as the content coming in has a stable "REST API" of markup structure, the rule file can do its job.

Next

That covers that background and basic information. Next posts will dive into how it will actually work, plus what is needed for Plone to evaluate it as a way of doing branding.

- Paul

posted at: 00:00 | permalink