cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject What do we need taglibs for?
Date Fri, 03 Dec 2004 11:40:49 GMT
Lots of emotions related to templating and/or taglibs lately, and the 
feeling that both camps aren't that far from actually saying the same 
thing...

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 }


Mime
View raw message