cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: What do we need taglibs for?
Date Fri, 03 Dec 2004 20:31:25 GMT
Please excuse this rather lengthy post. I'm trying to make a simple 
point. Why are we trying to cover all cases in a single generator? If 
you have a generator that can be configured to use any and all taglibs 
then you don't need any other generators. Just stick the appropriate 
tags in a template and let it run. Create a taglib for files, one for 
requests, one for java, one for python, one for ... etc. The list never 
ends. I think the sound approach is do our best to keep concerns 
separate. We can't prevent others from mixing concerns, but we can make 
them at least have to expend some effort and thought before they do.

On Dec 3, 2004, at 5:40 AM, Sylvain Wallez wrote:
> 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.

Ok, agreed. I have nothing against taglibs. I have no problem with 
using them in the implementation of a JXTG replacement. What I disagree 
with is having any and all taglibs as part of a single generator. I 
think the macro approach to formating injected data is much better. It 
allows things to be domain specific in ways that generally will not be 
done by a generic library. I usually don't need to format all 
ResultSets as a generic table. Formating product comparisons is 
different then then displaying the 3 best selling products. I want to 
be able to have a tag/macro that expands a product in the appropriate 
way so I can inject it into a product-comparison element or a 
best-sellers element.

I'm probably missing something in my understanding of what a generator 
is supposed to do, since it seems that many want it to do everything. 
The way I see it a generator should convert a data source to a stream 
of sax events. This is where things start. If my data source is a 
database, I need to get the required data and put it into the stream 
appropriately. If my data source is a Java object/s I need to extract 
the properties I need and inject them into the stream. At this point 
all I want is to produce a sax stream from the data. The resulting 
output should be the same if my data source was an XML file, a database 
or whatever. If I serialized immediately after generation I should be 
able to get a valid xml document that contains data only and no view 
information. All I should have done is extracted data from the model. 
Template generators should inject that data into a user defined 

Now, an example that has been brought up before is that of pretty 
printing a date.  Should this be handled by the generator? I think not. 
If the generator were to have a tag for a date, I believe it should not 
be concerned with formatting the date for the view. Rather, it should 
be concerned with injecting the date into the stream as data. It should 
take the date, whether from a database  or a Java Date, and inject it 
in to the sax stream as something like


Should this even be a tag backed by a Java class? I'm thinking a macro 
works fine. This requires no complex computations, just the extraction 
of data. Formating should be left to a transformer.

The problem as I see it is that by creating a taglib plug-able 
generator, you are inviting easy misuse. I don't see many use cases for 
mixing data from multiple types of data sources (such as concatenating 
"xyz" from an XML file and "abc" from a result set) so the idea of 
having generator that can deal with tags from different data type 
access libraries doesn't make a lot of sense.  (If I did have such a 
use case I'm pretty sure I wouldn't want to handle it in a geneartor) 
On the other hand as I said in a previous post, the approach of having 
a taglib plug-able architecture is sound. If someone wants a single 
generator that can do everything just like XSP, then fine let them 
write one. But make them write one. Make them expend the minimal effort 
of extending an abstract TemplateGenerator and configuring it to work 
with their required taglibs. Once the taglibs exist, it would take 
about 5 minutes to get it working. I just think that having each 
generator do one thing and do it well is a much sounder way to proceed 
then having everything in one.

I think it makes more sense to have unlimited plug-able rendering 
libraries for a transformer. This is where data should be formated and 
the view rendered. Sure people could abuse it, but that is their 
problem. If you want to render a calendar do it with data from the 
generator, render it in with a transformer. If this turns out to be a 
big performance hit for you, you may need to create your own custom 
generator. (Or a more efficient transformer)

On the other hand XSL extensions might be all you need to handle any 

I think with flow, we sometimes forget that the pipeline is the 
original controller. That is where we separate concerns. It is my hope 
that we do not encourage the creation of generators that render the 
view. Seven or so months ago when I first started working with cocoon, 
it was view rendering using JXTG that bit me. As the visual design of 
the site developed there were many templates that needed to be 
modified. Now we only convert objects to xml. All rendering is handled 
by the XSLT Transformer and a few style sheets. It is much easier to 

I understand that situations will dictate that performance is king and 
the option to quickly put together a generator that can do everything 
at once is very attractive. Both in terms of performance and 
development time. In those situations just do it. Just don't make that 
the standard way of doing things.

Thanks for listening.

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