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 template.
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
<date>
<year>2002</year>
<month>2</month>
<day>23</day>
<time>
<hour>12</hour>
<minutes>30</minuets>
<seconds>12</seconds>
</time>
</date>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 formating.
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 maintain.
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 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
