[Repoze-checkins] r698 - www/trunk/blog.repoze.org/entries

[Paul Everitt]

Author: Paul Everitt <paul at agendaless.com>
Date: Mon Feb 18 14:50:44 2008
New Revision: 698

Log:
Next post.


Added:
   www/trunk/blog.repoze.org/entries/what-sitetheming-2-20080218.txt

Added: www/trunk/blog.repoze.org/entries/what-sitetheming-2-20080218.txt
==============================================================================
--- (empty file)
+++ www/trunk/blog.repoze.org/entries/what-sitetheming-2-20080218.txt	Mon Feb 18 14:50:44 2008
@@ -0,0 +1,103 @@
+Plone Sitetheming Part 2: Why and What
+#label deliverance
+
+<p>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.</p>
+
+<h2>Motivations</h2>
+
+<p>Why pursue this facility? Who is it aimed at and what issues do
+they have with the status quo?</p>
+
+<p>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.</p>
+
+<ol>
+
+<li>People that produce high-quality designs won't want to learn Plone
+  templating.  Imagine if their HTML (and skills therein) was used,
+  untouched.</li>
+
+<li>Reducing the amount of "unique-to-Plone" stuff that is important
+to getting started can help reduce fear-of-the-unknown and learning
+curve.</li>
+
+<li>Sometimes this design already exists and doesn't need to be
+  "compiled" into ZPT/packages.</li>
+
+<li>Web designers probably don't want to run a Plone install to
+  maintain the the branding.</li>
+
+<li>Theme resources, such as CSS and JS, will be served from the HTTP
+  server directly.</li>
+
+<li>Focusing Plone on the semantic information unique to a single
+  resource/URL will promote other goals such as integration.</li>
+
+<li>It is possible that performance improves, if less is done in ZPT
+and Zope.</li>
+
+<li>If Plone moves to a more Python-friendly (WSGI) philosophy, then
+  theming non-Plone sites with the same artifacts is a benefit.</li>
+
+</ol>
+
+<p>Again, just to be clear: the single biggest goal is to be kind to
+civilians.</p>
+
+<h2>Sitetheming in a nutshell</h2>
+
+<p>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".</p>
+
+<p>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".</p>
+
+<p>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.</p>
+
+<p>More specifically:</p>
+
+<ol>
+
+<li>Save some HTML and other stuff.</li>
+
+<li>Make a rule file that defines spots in the theme that need to be
+replaced.  For example, the big block in the middle column.</li>
+
+<li>Later, as content is being served, blocks are pulled out of the
+content and merged into the theme.</li>
+
+</ol>
+
+<p>This diagram shows the basic idea:</p>
+
+<p><img src="deliverancediagram.png" width="374" height="416"/></p>
+
+<p>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.</p>
+
+<h2>Next</h2>
+
+<p>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.</p>
+
+<p> - Paul</p>