cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Fri, 03 Dec 2004 17:37:44 GMT
Leszek Gawron wrote:
> Jonas Ekstedt wrote:
> 
>> 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 :)

I cannot disagree more.

${myDate as month}

will do the above without mentioning tags (and will be much more 
Dreamweaver-friendly).

>> The current discussion about taglibs have focused very much on esql and
>> 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. 
> 
> Exactly. 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.

excuse me? what side effect does a SELECT have?

>> Taglibs (in my view) are primarily about converting
>> objects to SAX. 

If this is the case, then "taglib" is a *VERY BAD* name. I agree that 
some objects might be "sax-ified" differently, depending on user needs, 
but the name "taglibs" makes the syntactic and the semantic concern 
overlap and annoys people (like me) that ended up hating dynamic XML 
tags after promoting them for so long.

> Here are a few ideas for taglibs that only deals with
>> presentation of objects (as opposed to esql which also populates).
>>
>> * Bean renderers
> 
> <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"/> ?

I completely agree that the transformation stage is overkill, that's not 
my point.

I think that better than both you can do

  ${bean.startDate as YYYY-MM-DD}

>> * DOM renderers

excuse me?

>> * ResultSet renderers (ie renders a query made in flow)

are you kidding? regular iteration is all you need.

>> * Menus * Page navigation * Tabs (similar to tabs in CForm)

what?

>> * CForm tags

the above ${var as flavor} will do

>> * cinclude

no way

>> * Calendars (showing week, month etc.)

see above

> * 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>

OH COME ON! you can do a generator and cinclude a subpipeline for that.

> <snip/>
> 
> <radeox-string value="${project.description}"/>
> This clearly is a hack and should be implemented as taglib.

You will have to step on my dead body before that's the case.

> * 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 of
>> 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. 
> 
> Maybe we should stop using "taglib" word. What we're trying to do may 
> simply be harmed by the emotions that this phrase carries.

No matter what you call it, if you want to have dynamic XML tags, you 
will hurt yourself, your wiki example is the kind of things that gives 
me the creeps.

-- 
Stefano.


Mime
View raw message