So, why do we need taglibs for? Let's consider two examples that led me to write JX macros, which are nothing but taglibs. One is in Cocoon, it's the CForms template language, the other one is on a project, used to render the path of a node in a tree.
First use case, CForms' jx-macros.xml:
We have the FormsTransformer, so why would we need forms template be handled in the generator? The answer is simple: the template structure can depend on the form contents.
Sure, the flow gives the form object to the view, so we could use the basic JX control structures to do all the job. But macros gives the template writer a higher level of abstraction, meaning he can directly use widgets and their names rather than going through the widget tree traversal API (which *is* code).
These macros also populate some template variables (e.g. "widget", "repeater") that can be used for pure-JX control structures (e.g. testing that a repeater is empty, that some section is visible, etc), making life easier for the template writer and standardizing form-related variable names.
Second use case, displaying a node's path:
I worked on a project where we had to display lots of nodes in a tree in a way similar to e.g. dmoz.org categories [1], using their path. Should we iterate backwards a node's ancestor tree to display its full path in each and every location where a node has to be displayed? Nah, I wrote a simple macro, which allowed me to write:
<topic:path node="${mynode}"/>
for "passive" display and
<topic:linked-path node="${mynode}"/>
to have each node in the path holding an hypertext link.
In this case, the macro/taglib is actually a formatter.
Now the ESQL case:
The main question is "where should the query be written"? I agree that writing SQL statement in the template is ugly and mixes concerns (even if very powerful when you master this gun). That's a business-logic concern and should therefore be written in some kind of controller.
But the main question that led people to fight around ESQL seems to me related more to the actual place (and time) where the query should be executed, people arguing that if the query is written in the controller, we loose some control in the template, and on the other side that if the query is executed in the template, we mix concerns.
But why should the query be executed at the place where the SQL statement is written? Without throwing in the big Hibernate, simpler systems such as Brian McCallister's jDBI [2] and iBatis [3] allow to have named and parameterized queries where the SQL code is totally separated from the place where the query is actually executed. We can then have a controller of some kind (or simply a query repository) prepare a statement given a name and parameter values, and then let the template execute it when needed. Just as in Hibernate, lazy loading of the result set.
Taglibs are to templates just what factorization in classes and methods are to Java code. Taglib features could equally well be provided as extension functions to the expression language, but writing them in XML (either with tags or attributes) just seems more consistent with the XML world of the view layer.
Sylvain
[1] http://search.dmoz.org/cgi-bin/search?search=xml [2] http://kasparov.skife.org/jdbi/ [3] http://www.ibatis.com/
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
