Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
In mulling over the recent discussion of "display logic" in templates, I think I spoke too early and too disparagingly about taglibs. I am thinking of 5 different classes of template systems.
1) simple interpolation
3) [PAJ]SP: embedded code
4) XSLT: declarative transformations
5) XMLC: DOM manipulation
Tavis' Template filler may have started out in class 1, but it now fits squarely in class 2. Chuck's suggestion to use [tag][/tag] delimiters helped me to realize how similar it is to DTML. Then when I thought of how to implement DTML in a general way, I realized that that is exactly what taglibs are.
[for bar in seq]
<for name="bar" sequence="seq">
Taglibs are a way to plug in specialized implementations. Instead of laboriously hard-coding a very small set of supported tags, Taglibs provide a generic framework for implementing arbitrary functionality. The framework is sufficient to implement at least 90% of DTML. (The only slightly problematic part of DTML that I can see is try/except/finally/raise, but I may change my mind after I have looked at it more.) The taglib classes become "bytecode" and the template filler becomes the "interpreter".
Some imporant goals of using a template system are:
1) separate "application logic" from "presentation logic"
2) allow the presentation designer to access application objects using tools with he is familiar (visual design tools)
The [tag][/tag] syntax allows the designer to use the template system with tools that don't understand special tags, but as tools add support, it may be better to move to the more standard <tag/> syntax, possibly with proxy content for visualization.
<!-- this content will be replaced by the mytag implementation -->
If the tool does not support arbitrary tags, you could turn them into divs and spans and use a simple XSLT transform to convert it to a syntax that the template filler prefers. (This approach also works with DOM manipulations like XMLC.)
Summary of rambling thoughts: Taglibs are to templates what XML is to HTML. They are a clean way link application logic and presentation logic. While the full gory details of the Java implementation may not be directly applicable to PlateKit, studying that implementation may give insights to design it for growth. Especially as more designers and developers become familiar with taglibs, a webware clone would help to encourage migration.
I would love to follow through with this, but I have too many half-finished projects sitting around. I would encourage whoever works on PlateKit to study the taglibs design.
BTW: Please use this email address now: tshumway@... tshumway@... will not get to me anymore. 8-(