#223: removing DTML files in favor of z3c.zrtresource files
- Contents
- 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:
- 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.
- all .css.dtml and .js.dtml files have to be rewritten using the z3c.zrtresource syntax
- zcml directives will be added in order to plug the files
- 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
context customization
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
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?
Customerize?
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.