SOPE currently allows for two different template formats, the traditional WebObjects one (with the # addition) as well as a new XML based one. This document tries to outline some pros and cons for each.
work in progress ..., just collecting ideas for now ;-)
TODO: need some intro to both formats
TODO: need some examples for each pro and contra
Important: Note that WOx does not try to replace WO wrapper templates! Both formats are complementary and can be mixed. What template format is better really depends on the actual use case and both have strength and weaknesses.
Advantages of .wo "Wrapper Templates"
Advantages of .wox "XML Templates"
Another option are SAX drivers which emit XML for different template formats, like PHP or ASP. Not too difficult!
Disadvantages of .wo "Wrapper Templates"
A lot of the issues come from the fact that the templates are wrappers, that is, separate files.
Disadvantages of .wox "XML Templates"
Some text from the sources .. (to be cleaned up)
In general we have two kinds of templates, XML based ones and "hash" based ones. The 'hash' templates are simple scanners for strings which start and end with "<#" and "</#", while the XML based templates are valid and "namespace'd" XML files. Practical difference: - XML templates can be created, parsed, transformed, ... with any standard XML tool - hash templates can be used in a non-tag way, eg this is a valid template: <a href="<#MyHRef/>">blah</a> Since unlike the XML parser the hash parser only scans for "<#", this is OK. - hash templates use "wod" files for declarations which may or may not improve the visual clutter in the template itself - XML templates do not need to have a 1:1 mapping from tag to WODynamicElement and the mapping between tag and element is completely controlled by the builder while for hash templates you always use the actuall WODynamicElement subclass name in the .wod file
TODO: write more
Some other associations which might make sense:
You can also use it too shorten all kind of pathes, eg to access session variables, you could use something like:
Though this particular case is probably not worth the effort. On the other side this syntax increases the semantic value of the XML file and could be used to validate (using XML tools) whether the contained value is an available session key.
Good matches with namespaces ...
Something which is a bit "surprising" is that namespace "clutter" is pretty low for associations and elements. The worst case would be, if you would need to specify a namespace prefix for each attribute. But as mentioned, this is seldom necessary:
<var:foreach list="addresses" item="address"> <var:string value="lastName"/>
... matches very well for purely dynamic tags, and it matches HTML tags quite well, and highlights pretty well which parts are dynamic:
<td align="left" width="80%" var:bgcolor="backColor"> <img rsrc:src="filename.gif"/>
One example where it doesn't match well is:
Do you transform the WOx templates into .wod and .html
strings of the wrapper format and pipe that into
A: No. For SOPE we made the whole template creation mechanism pluggable so we don't need to resort to use available public API.
So both, the .wo wrapper builder and the .wox builder are regular template formats supported by SOPE. Take a look in NGObjWeb/Templates if you are interested.
How fast are WOx templates?
A: Parsing WOx templates is slower than parsing WO templates. First the DOM tree will be built driven by SAX events, then the DOM tree will be converted into the dynamic element tree.
We don't consider that an issue, since in a deployed app component templates are cached and during the development 10ms more do not matter. See next question if you want to do a lot of parsing ;-)
At runtime evaluation WOx templates are exactly as fast as WO templates - the result of parsing is in any case a regular WOElement tree.
Parsing templates is too expensive, because I
compose them dynamically in my application!
A: Yes, in this case WOx may be too slow. Actually SOPE also contains NGObjDOM which is basically the "reverse" approach to WOx.
Instead of building a WOElement tree out of a DOM, it allows to use a DOM tree directly as a dynamic element.
This approach is used in OGo Publisher, because each page is treated as a separate component but only used once (so the template creation would be superflous).
Update: NGObjDOM now lives in the Recycler.
If I have a dynamic element or component with a lot of bindings, the WOx becomes hard to write in XML.
A: If you have a lot of bindings on a single element, a WO wrapper templates might indeed be better.
On the other side WOxElemBuilder are free to use DOM structure to represent bindings! That is, instead of putting all bindings of the element into XML attributes, you can use child tags which are converted into WOAssociations instead of WOElements.
But of course this requires custom coding (which may be worth the effort for such complex elements!)