#223: removing DTML files in favor of z3c.zrtresource files

Contents
  1. Definitions
  2. Motivation
  3. Assumptions
  4. Proposal
  5. Implementation
  6. Deliverables
  7. Risks
  8. Progress log
  9. Participants
by Tarek Ziade — last modified Mar 02, 2008 09:42 PM

Plone uses DTML to be able to do some templating in CSS and JS files. The DTML templates are getting a bit deprecated in Zope, and are obfuscating the CSS and JS files. This PLIP proposes an alternative templating engine that is not intrusive

Proposed by
Tarek Ziadé
Proposal type
Architecture
State
being-discussed

Definitions

 

Motivation

This proposal will be rewritten soon, considering a more global customize mechanism, and ongoing feedback on DTML usages

Plone uses DTML to be able to do some templating in CSS and JS files. The DTML templates are getting a bit deprecated in Zope, and are obfuscating CSS and JS files.

 

Assumptions

  

Proposal

A alternative template engine is z3c.zrtresource, which allows regex and TAL-based string replacement. The nice thing about it that the commands are set in comments. In other words, the files are still valid and readable.

Example (taken from here):

 

/* Replace "foo" with "bar", but only 3 times */
/* zrt-replace: "foo" "bar" 3 */

/* Do a group regex string substitution */
/* zrt-replace: re"(?P<prefix>[a-z]*)foo" "barg<prefix>" */

/* Replace the strng "foo: with the resource URL at runtime, everywhere */
/* zrt-replace: "foo" tal"string:${context/@@absolute_url}/@@/foo" */

 

 

Implementation

The work to be done is quite mechanical:

  1. for each existing DTML, a test will be added to check its rendering. This will provide for each template a rendered js or css file we can use in the tests on step 4.
  2. all .css.dtml and .js.dtml files have to be rewritten using the z3c.zrtresource syntax
  3. zcml directives will be added in order to plug the files
  4. The rendering tests will be run to make sure no regression has occured: the rendered files should be the same than in DTML.

A zrtresource directive is quite similar to a resource directive. For example:

<zrt-resource
    name="site.css"
    path="css/site.css"
    />

 

Deliverables

These files will be transformed as .css and .js files, with the included z3c.zrtresource syntax:

./Archetypes/skins/archetypes/archetypes_zmi.css.dtml
./Archetypes/skins/archetypes/content_types.css.dtml
./Archetypes/skins/archetypes/table_view.css.dtml
./CMFEditions/skins/CMFEditions/compare.css.dtml
./CMFPlone/skins/plone_3rdParty/s5_pretty.css.dtml
./CMFPlone/skins/plone_3rdParty/s5_slides.css.dtml
./CMFPlone/skins/plone_deprecated/presentation.css.dtml
./CMFPlone/skins/plone_styles/IEFixes.css.dtml
./CMFPlone/skins/plone_styles/NS4.css.dtml
./CMFPlone/skins/plone_styles/RTL.css.dtml
./CMFPlone/skins/plone_styles/authoring.css.dtml
./CMFPlone/skins/plone_styles/base.css.dtml
./CMFPlone/skins/plone_styles/columns.css.dtml
./CMFPlone/skins/plone_styles/controlpanel.css.dtml
./CMFPlone/skins/plone_styles/deprecated.css.dtml
./CMFPlone/skins/plone_styles/forms.css.dtml
./CMFPlone/skins/plone_styles/generated.css.dtml
./CMFPlone/skins/plone_styles/invisibles.css.dtml
./CMFPlone/skins/plone_styles/member.css.dtml
./CMFPlone/skins/plone_styles/mobile.css.dtml
./CMFPlone/skins/plone_styles/navtree.css.dtml
./CMFPlone/skins/plone_styles/ploneCustom.css.dtml
./CMFPlone/skins/plone_styles/portlets.css.dtml
./CMFPlone/skins/plone_styles/print.css.dtml
./CMFPlone/skins/plone_styles/public.css.dtml
./kupu/plone/kupu_plone_layer/kupuplone.css.dtml
./CMFPlone/skins/plone_deprecated/plone_minwidth.js.dtml
./ResourceRegistries/skins/ResourceRegistries/test_rr_2.js.dtml

Then, for each file, in each concerned product, a zrtresource ZCML directive will be added.

The deliverable will also include the tests that will be written to avoid regression

 

 

Risks

Plone will depend on z3c.zrtresource. This package is quite used and maintained in the Zope 3 community though, and since it is working on a delimited area, it is not hard to debug and to make evolve.

Progress log

 

Participants

 

Customerize?

Posted by Hanno Schlichting at Feb 23, 2008 10:19 PM
How does one customize these files TTW?

Some kind of integrator story needs to be in place for these files, though I would love to be able to move them out of the skins folders.

context customization

Posted by Tarek Ziade at Feb 23, 2008 10:39 PM
Yeah, that's the same story than page templates in zope 3 views : the customization is doable only through the context, so maybe we could work on a panel control, where we would be able to provide values for variables used in the files.

This panel would be extensible, so one can add custom variables.

That's how css dtml files used to work with properties pages for colors iirc

A few considerations

Posted by Darryl Dixon (Winterhouse Consulting Ltd) at Mar 02, 2008 09:29 PM
Just a few brief thoughts on this:

1) It looks(?) like all the regular expressions are compiled at runtime? This could be very, very expensive, and potentially provides an awful lot of rope for the beginner to hang themselves with (See ResourceRegistries, packer.py for an existing example of this).

2) DTML templating with javascript and CSS provides other useful constructs than simple variable replacement, including dynamically generating CSS class declarations etc based on existing portal types. What will be the replacement for this functionality with this PLIP?

Performance and readability

Posted by David Charles Todd at Jun 06, 2008 08:36 PM
I second the performance concerns. In my use of plone, proxy caching isn't very useful, since I require the majority of my users to login. Performance is a real issue.

My other concern is readability. I'm not a fan of things encased in comments. I find them very hard to read, and easy to get syntactically wrong, thus increasing coding time.

performances and readability

Posted by Tarek Ziade at Jun 07, 2008 10:59 PM
@esrever_otua:

1) compiling regexpr is not more expensive than compiling DTML
   expressions afaik, but I can provide benchmarks for this.

2) this wouldn't change since z3c.zrtresource gives you the ability
   to call any code to generate something, it is just another template engine.

@hacksaw: I find that having a CSS that is *still* a CSS is more
readable that a CSS obfuscated by DTML markup. It makes it still
usable by non-developers. Notice that you can use TALES expressions
instead of regexprs.