I think the reason for taglibs are that rendering an object is often more complicated than simply outputting a value. For example, suppose you want to render a calendar covering the current month. This is a typical component that would lend itself well as a tag class. The template writer would simply do:
<calendar:month current-date="${myDate}"/>
The tag might output something like this:
<month value="2"> <week value="12"> <day value="5" name="Monday"/> <day value="6" name="Tuesday" current="true"/> <day value="7" name="Wednesday"/> ... </week> ... </month>
Later transformations would transform it into a table or whatever. This type of calendar would be very hard to do for a template author without the help of a tag library.
I have completely no time these days so I was just waiting for the single post to say: Cannot agree more here :)
The current discussion about taglibs have focused very much on esql andExactly. Everyone concentrated on ESQL as a taglib while this is the WORST example there is. ESQL does a lot of persistence logic and can have enormous side effects. Taglibs should have no side effects at all.
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs.
<jx:set var="ignored" value="${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate, cocoon.consumer"/> - is this one better than the taglib? Or should I implement a stylesheet that would parse my 100kB xml file just to look for <dateutils:prettydate value="2003-01-01"/> ?Taglibs (in my view) are primarily about converting objects to SAX. Here are a few ideas for taglibs that only deals with presentation of objects (as opposed to esql which also populates).
* Bean renderers
* DOM renderers
* ResultSet renderers (ie renders a query made in flow)
* Menus * Page navigation * Tabs (similar to tabs in CForm)
* CForm tags
* cinclude
* Calendars (showing week, month etc.)
* wiki renderers currently I do something like to parse wiki syntax:
function radeoxToSAX( str, consumer ) { var radeoxStr = radeoxEngine.render( str, radeoxContext ); var buffer = new java.lang.StringBuffer("<root>" ); buffer.append( radeoxStr ) buffer.append( "</root>" ); var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( buffer.toString() ) );
var parser = null;
var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
includeConsumer.setIgnoreRootElement( true );
try { parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer ); } finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
<jx:macro name="radeox-string">
<jx:parameter name="value"/>
<jx:set var="ignored" value="${cocoon.session.radeox( value,
cocoon.consumer )}"/>
</jx:macro><snip/>
<radeox-string value="${project.description}"/>
This clearly is a hack and should be implemented as taglib.* ValueList renderers a taglib that supports displaying a narrowed list of values, searchable, paginable and so on
The items above are in my view better examples of the benefits ofMaybe we should stop using "taglib" word. What we're trying to do may simply be harmed by the emotions that this phrase carries.
taglibs. They're all about how to render an object. The object is
populated in flow but how to render it is implemented in the tag
classes.
Sure all taglibs/convertors/renderers could be implemented as stylesheets or custom transformers. But creating a pipeline with 15 transformations (which by the way mainly would do identity transformations and expand only specific tags) is neither performant nor elegant. In case of custom transformers it's also never easy.
-- Leszek Gawron [EMAIL PROTECTED] Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
