cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Fri, 03 Dec 2004 03:51:17 GMT
I was working on an extremely long e-mail about this but Torsten,  
Stefano and a repentant Miles covered most of my points. Thanks for the 
help and for allowing me to waste my time :-P


It seems that you are trying to do more then just replace the current 
functionality JXTG. You want to include the possibility processing the 
kitchen sink. I think this is what's bothering many of us. This will 
lead to breaking the separation of concerns. While implementing this in 
a template may seem better then implementing it in an XSP, in the end I 
suspect it will be just as ugly. The only thing that will change is the 
syntax. Semantically, it will be just as ugly. There is already too 
much power in the existing JXTG.

On the other hand, I find the idea of a general template generator 
intriguing. I think you might be on to something, but I think you are 
missing it. Ok so you want a replacement for JXTG, create a tag library 
and have the template generator use it. You want the functionality of 
ESQL without XSP, create a tag library for it. Want to process CSVs, 
write a tag library for it. Want to process excel spreadsheets, create 
a tag library.

The problem is that generally you declare the libraries in the document 
in which they are used and can use as many libraries as you want. This 
is where the evil part of tag libs comes in. It allows you to do 
anything and everything in one place. No separation of concerns can be 
enforced. View, controller, model all can be intermingled. Suppose, 
that instead of allowing all Tag Libraries to be used by the generator, 
each generator could only use one library. That is JXTG could only 
process JXTG tags, SQLTG could only process ESQL tags, ExcelTG could 
only process EXCEL tags, etc.

TemplateGenerator is a perfect candidate for an abstract class. Each 
subclass just needs to have a Tag Library with which to work. This 
makes it much easier to implement other template generators just 
implement a new Tag Library and some constructors. Of course nothing 
prevents someone from adding multiple libraries to their generator 
should they choose to do so. They can deal with the consequences.

This gives you the flexibility in design you want. It gives you the 
functionality that you want, since it is unlikely that you will want to 
access java objects and then access a database. It also helps limit the 
abuse that tag libraries can engender.

Just my 0.02 €.

Now if I could just come up with a way to keep all html tags out of the 
JX templates.

Glen Ezkovich
HardBop Consulting
glen at

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

View raw message