[Zope3-dev] Siesia: A new UI for Zope 3

[Stephan Richter]

Chatlog: 
http://irclogs.espnow.net/zope3/2004.05.04.log
http://irclogs.espnow.net/zope3/2004.05.05.log

After concretely defining some terms and some struggle to find an example, 
Arnia and I started to approach a common level of communication. :-)

The issue at hand, really, is that Zope's skinning mechanism sucks. The 
concept of layers is unique to Zope and is not used in any other advanced UI 
transformation technology. The common pattern to use is the concept of a 
"transformation pipeline", which takes a fundamental representation of the UI 
(called root markup) and converts it to the final output (called target 
markup) using several transformations in a specific order. It is equivalent 
to Unix pipes. The worst is, Paul (Everitt) has told us this fact as long as 
I am working on Zope 3. 

After realizing that these changes would not happen for 3.0 (X3.0), the goal 
was now to come up with a way to support transformation pipelines while 
keeping backwards compatibility. Arnia's main concern was to reuse some 
existing XML standard for declaring the pipelines and declarations. He 
suggested to use Cocoons syntax and that should be no problem, since ZCML can 
easily be extended to support Cocoon's namespaces. Here is a crude sample 
declaration of a transformation pipeline:

<pipeline id="flashtransformation" pathcondition="/flashfiles/*">
  <transform type="xslt" file="uitogeneratorformat.xslt" />
  <transform type="xslt" file="customflashwidgets.xslt" />
</pipeline>

Note: One type of transform could be "tal".

The other concern that was raised was about transparency. Arnia did not want 
the designer to worry about the data/code aspect, but only about the 
transformation of the UI.

After some compromises and Arnia almost falling asleep on the keyboard, we 
came up with some initial design ideas that allow us to keep 
backwards-compatibility and introduce Arnia's (and the other Netally folks) 
ideas and changes gradually.

First of all, instead of ripping out the guts of the Publisher and the 
Presentation Service, we decided to leave this code alone. Instead, we will 
have an 'ITransformer' interface, which is the provided interface of a 
'TransformerView'. If someone wants to use pipeline transformations instead 
of classical views, s/he can simply replace 

<browser:page for="IFlashFile" name="view.html" template="view.html" />

by

<browser:transform for="IFlashFile" name="view.html" />

which creates a view from (IFlashFile, IBrowserRequest) to an ITransformer 
object. Like any other view, the 'ITransformer' has a '__call__()' method 
that will generate the XHTML. But instead of using a page template to produce 
the output, it uses applicable transformations instead. Let's go through an 
example:

1. The Publisher receives a request for /flashfiles/video.swf

2. Since 'video.swf' is an 'IFlashFile' object and "view.html" is the default 
view, an 'ITransformer' object, called 'transformer', is created.

3. The Transformer looks now through all utilities (could also be done through 
adapters) providing 'ITransformationPipeline' to see which pipeline fulfills 
its conditions. It finds "flashtransformation". (BTW, this is very similar to 
our recently-discovered events and subscription adapters patterns.)

4. The transformer applies now both transforms. Most likely the transformer 
provides some kind of root markup object, but that's left up to the policy of 
the transformer to decide. I am waving my hands here, since I am not sure 
what will be needed.

5. The transformer expects the last transform to output valid target markup, 
which it returns.

That's it! The nice thing about this approach is that people can provide 
alternative implementations of the 'ITransformer' interface, implementing the 
policy they like. This approach also only requires the coder to make a 
decision between old- or new-style views. If a project decides to use the 
new-style approach, then the designer can just define transformations and not 
even worry about any other details.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training