Friday, June 6, 2008

PSPS: The Work Cycle of Theming Deliverance, DVNG, pagetypes, themesets, compiled themesets, debugability...so many words, so many details.  Let's step back and look at how an ecosystem (gag) of theming might work. This proposal describes a system where themers make themeset packages and share them at themeset sites.  Site managers can then browse, install, and update these themeset packages with a friendly user interface. Big Goals We want to make it easy for a themer to: Make a theme Share the theme with others We want to make it easy for a site manager to: Find and use themes It's easy to get mired in tons of details: Who is this "themer"? What is and isn't a "sitetheme"? What are the benefits of this approach to sitetheming? For now, let's focus just on how we could reinvent the process of making themes, providing something substantially easier from end-to-end. How It Could Work Let's break the world of theming into 3 parts: Make.  The work to produce and package a "theme". Distribute.  Put the theme in an organized place where people can find it.  This place is specifically designed to maximize convenience. Use.  Find available themes, use them, and get updates. What are some crazy things we could do to really change the game on"easy"?  How might we make this a significantly competitive part of our story? Make Deliverance helps themers avoid learning a framework's architecture and APIs.  What if they could develop and test a theme without installing any unusual software? For example, imagine the first, simplest way to develop a theme: 1) Create an HTML file for the theme, some CSS and images, and make sure they look alright.  This just HTML as files, so "alright" means"Open File" in a browser. 2) Next, make the Deliverance "themeset" file and some sample content pages. 3) Run "zip" to package it all up. 4) Use "curl" to POST the zip file to a web service URL.  This webservice returns a packaged, compiled themeset as a zip file. 5) Unpack the resulting zip file and view the sample content, themed as appropriate under the themeset rules. We could foolproof this step by providing a zip file that had a sample themeset, ready to go.  You just run a "run.sh" or "run.bat" in the zip file's unpacked directory.  We could even include the curl and wget binaries for Windows. This approach is a nice, small-step for the not-yet-committed.  How could we, though, make this process more productive for people that regularly theme? We could write a Firefox extension that put a GUI on the operations and options, hiding the upload/download as background tasks.  This extension could start small: point at a themeset, a button to view the results, and links to the themed sample content. Over time, the extension could do more: show log messages about rule matches, provide a GUI to edit and validate the themeset file, make thumbnails, and upload to distribution servers. Finally, those who are committed to Deliverance could use easy_installto grab the Deliverance themeset "compiler" itself, and not rely on a web service.  This would be a command-line tool that used lxml/libxml2 to generate the compiled themeset and package it up for distribution.We could also include a Paste-based local HTTP server that did theming on-the-fly. Distribute A "compiled themeset" is a very, very simple package that can apply one or more look-and-feels to content based on some criteria.  It uses technology that is completely safe to distribute: no programming language, APIs, access to the filesystem, access to the web application, etc. Because they are safe and commodity, it makes sense to share them and pass them around.  We can have sites that provide hosting of themes,using a somewhat-smart themset server providing the following: 1) List packages. 2) Compile themesets.  This serves the purpose above, allowing themers to make themes without local software.  It also, though, provides some security check: rather than trust the themer's compiled result, make it on the server. 3) Host versioned URLs to static theme resources.  Google recentlyannounced that they would provide stable URLs for important JavaScript resources.  Themeset servers could do the same for the images and CSS that go with a particular version of a theme. With this, using a theme becomes even easier, as the static resources point to a stable, versioned URL that sets very long expires headers. In fact, we could leverage a free CDN such as Coral, without themers really having to understand it.  (And if the site manager didn't like it, they could run local versions.) By doing so by default, we make such things easy. It would be tempting to have themeset servers that are just dumb static-file sites.  However, we should preserve the idea that the themeset server generates the compiled themeset, rather than trusting the theme makers.  Note that, rather than a full web application, you could still use Subversion with hooks that execute scripts. In the workflow for a consulting project, you really don't think of putting the artifacts on a public site.  Thus, it should be easy and normal to run a private themeset server for a consulting project. (Alternatively, produce the themes and just put them in the buildout for the project, if the customer will never want to select new themes.) Why zip files that aren't eggs?  Foremost, a themeset package isn't "executable".  The process of installing a themeset shouldn't accidentally run some Python code.  We could leverage eggs, but that inherits quite a few contracts that might be stifling for the goal of"easy". Use We now have lots of themeset packages available at various public and private themeset servers.  How can we radically improve how site managers leverage all this? First and foremost, make sure this part of the equation is dirt-simpleand reliable.  We can do so by moving most of the software complexity to the "Make" step: a compiled themeset is just an XSLT file plus some static resources and packaging artifacts.  All the work for parsing the theme(s) and the rules was already done in the compilation process. Next, we provide a web GUI for configuration.  This allows operations such as: Browse themeset servers to find and install new/updated themeset packages List the currently installed themeset packages Change the active themeset to a different one Remove an installed themeset Where should this GUI be located?  It's natural for Plone to put thisin the 'site setup" as a configlet.  There are reasons, though, thatthis might not be the only place to consider: Deliverance is about corporate identity across multiple sites and multiple systems.  It makes sense to centrally manage your themes from outside a particular Plone site.  (OTOH, the people doing this might not want a GUI.) It is possible to have themeset configuration on a subsite basis. There are tons of opportunities here for fresh thinking about theme configuration, and most will prove easy to implement.  We should be open to new ideas on this aspect. Summary Making, distributing, and using "themes" is an important cycle to look at for Plone's strategic planning.  Doing a superlative job at this part would make a deep impact on Plone's initial perception.  Doing this job in a strategic way, where we think more about how Plone fits into the larger world for themers, integrators, and site managers, is worth discussion. 11:18:38 AM   comment []

Deliverance PSPS Update I've worked the last couple of days full-time on Deliverance: Themeswitching Demo I worked with Martin Aspeli, showing to use the new themeswitching features on the Deliverance trunk.  For this I made a small tutorial. (I plan to re-do some of that tutorial, as I now understand more about WSGI filters.) DVNG I've been talking on the Deliverance list about an experimental rewrite of Delivernace called DVNG. After the PSPS we solicited input on what was needed in Deliverance for Plone theming and Ian (with Wichert and others) came up with a proposed spec. This is an experiment in implementing those capabilities, along with an emphasis on: speed, reliability, debuggability, and extensibility. DVPlone Since the PSPS is doing a follow-up at the symposium this week (e.g. today), I wanted to make a prototype of ideas on how my ticket might work.  Thus, I'm pretty close on one approach to doing so and have a writeup that contemplates the big picture for theming. I'm working on a writeup for this which I'll post later. 10:12:50 AM   comment []