A new themes engine for CPS

(originally published on 2009-06-10, this blog entry has been the original specification of CPSDesignerThemes)

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.

About CPSSkins

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.

CPSDesignerThemes

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.

Related stuff

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.