Today, I'm going to write a bit about a project that has been on my mind for a few weeks, now : replacing CPSSkins by a theming engine more suited for professional web designer work.
CPSSkins has been designed with a very clear purpose in mind : allowing functional administrators without technical skills to design their own themes. For this, it comes with a graphical through-the -web editor, in which users can drag and drop page blocks around, upload images, and moreover define and apply styling information ! This is a huge piece of work, and at first sight, it looks like a real achievement, so why should we take the plundge and switch to some other system, that has yet to be developed ?
In short: because it's not targeted towards the people that will do the real work. CPS being a professional tool for content management, these are mostly web designers. Even in the case of non-profit organizations, the general investment and involvement in the system justifies to spend a bit on the design. The days of being stuck because the web design doesn't allow for any evolution of content are way over. Professional designers are now used to skin blog platforms and content management systems, this is their bread-and-butter. Overall, skills in HTML and CSS have spread a lot since CPSSkins has been launched.
Sure, the drag-and-drop and wysywig approach appears to be the easy way, and you definitely can adjust a few things in real time while you're receiving feedback, but let's face it : for web designers, it's a burden. I shall now list a few practical reasons why :
- why learn a bunch of new concepts (Page block, Cells, Templets), if one already knows how to obtain the same results with standard HTML while those concepts, though simple, have no application outside of the CPS scope ?
- sitting at a high level, CPSSkins could not handle the full expressivity of HTML and CSS by any chance. Therefore, it tampers with the designer's creativity. A few specialized designers know how to intertwine their CSS classes with the dynamical ones generated by CPSSkins to obtain what they want, but reaching that level requires lots of investment.
- designers often work before hand with a purely static site. For big, enterprise, installations, it's quite common to see the design been made by a designer that won't participate in the integration process. The client would even expect to validate the design before the integration work starts. Consider reading the previous point again...
- parts of CPSSkins have in effect been obsoleted by CPSPortlets, and were kept for backwards compatibility, I suppose. This brings a lot of confusion. Moreover, the majority of user-level customizations can be done at the level of CPSPortlets.
It turns out that I hang around with graphic designers a lot these days. Sadly, because of these reasons, I haven't even tried to show them how to work with CPS. I knew that'd be way too complicated: too much information to pass.
What should be neat
I'd like a skinning engine for CPS to be really easy for web designers, meaning that they should be able to work as if they were doing a static site. This is what themes for dotclear look like, for instance: a hierarchy of HTML templates with a few calls to dynamical content areas. Even further, I'd like to restore one of the main original strengths of Zope Page Templates : the designer should be able to work on the templates directly with its favorite browser or HTML editor, in a transparent way, without even a CPS instance to start with.
There are some really fine principles within CPSSkins that I'd left totally unchanged. The separation of content and presentation being done between CPSPortlets and CPSSkins is really spot on. Local themes association and the whole theme negociation process are also excellent and should be pushed even further.
As a matter of fact, I already have an early prototype for this. For now, it's called CPSDesignerThemes. I'll publish a roadmap soon, but let me show first how it works.
Like CPSSkins, CPSDesignerThemes interfaces with CPSPortlets for the separation of presentation and content. Portlets are naturallly grouped by slots, and all that CPSDesignerThemes does is to insert them in the theme page, at the right place, with the right frame. The theme page itself is standard XHTML with additional attributes.
Here's how a call to a portlet slot looks like:
<div cps:slot="doc_actions" style="float:left;"> <div cps:portlet="frame" style="border: 1px solid black;"> <span cps:portlet="title" style="font-size: 120%">The title</span> <div cps:portlet="body">The body of the portlet is here</div> </div> </div>
The cps:slot attribute indicates that portlets belonging to the "doc_actions" slot have to be put inside this <div>. The second <div> is the beginning of the portlet frame. It will be repeated for each portlet. Again, one can use any tag. I believe cps:portlet="title" and cps:portlet="body" to be rather straightforward.
The point is that the engine doesn't care what elements you decide to use. It's only about the attributes. While working on the theme as a static site, the browser should simply ignore the attributes it doesn't understand. Firefox does. There's also no assumption on the hierarchy besides the fact that cps:portlet="title" and cps:portlet="body" have to be somewhere inside the "frame", which must be inside the cps:slot. For instance, this would be also valid:
<div cps:slot="doc_actions" style="float:left;"> <h2>Document actions slot</h2> <table><tbody><tr> <td cps:portlet="frame" style="border: 1px solid black;"> <img src="pict.png"/> <h3 cps:portlet="title">The title</h3> <div cps:portlet="body" class="a_body"> The body of the portlet is here </div> </td> </tr></tbody></table> </div>
That's it. The icing on the cake is that the rendering is much faster (at this stage of development). I also expect the resulting pages to be lighter.
For people worrying about their existing CPSSkins themes, let me add that it will be rather easy to me to write a rendering mode for CPSSkins that would actually output themes for CPSDesignerThemes.
For completeness, I should mention two concepts that are really close in spirit, but not enough to be directly leveraged.
The first is Edge Side Includes (ESI), a markup language to use with HTML pushed by a few big bandwidth players, whose purpose is to trigger insertions of dynamical content. The idea here is that the main page is being cached by some reverse proxy that also interpretes the ESI markers. The difference lies partly in the portlet lookup, that depends on the current position in the hierarchy, the connected user, the guard, etc. Also, the idea of having the theme render directly in a browser as a static site could not be kept with ESI. The funny thing is that CPSSkins has ESI support
The second that comes to my mind is deliverance, a popular downstream WSGI skinning engine. This would be useful for instance to grab the main content and rewrap it. Probably, all that CPSDesignerThemes does with one theme could be done by a set of deliverance directives, but this is far from the wished transparency to the web designer.