However...
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 hard-bop.com http://www.hard-bop.com
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
