cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Fri, 03 Dec 2004 20:11:42 GMT
Stefano Mazzocchi wrote:
> 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).
Sure - but - isn't this only a change at syntax level?. You are 
describing a convertor here - something that has been discussed a few 
threads before and what Jonas implemented as
#{myDate#full}.

> 
>>> 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?
these:

<esql:query>insert into task values ( something, something ); select 
@@identity</esqu:query>

still a select from template point of view.

>>> 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 
This mainly is the case. At least for me.

> 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}
Sure. Still I would like to render my date specially if the date is 
before some point in time. My syntax would be:

<dateutils:pretty-enhanced-date value="${bean.startDate}" 
turning-point="2004-01-01"/>

This way I can achieve same formatting across the whole project.


> 
>>> * DOM renderers
> 
> 
> excuse me?
not going to defent examples that I did not give. Jonas? :)

> 
>>> * ResultSet renderers (ie renders a query made in flow)
> 
> 
> are you kidding? regular iteration is all you need.
agree here

> 
>>> * Menus * Page navigation * Tabs (similar to tabs in CForm)
> 
> 
> what?
Jooonas? :))

>> * 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.
OH COME ON! :) Transformation to pretty print a date is an overkill. 
CInclude for string pretty printing is not?

Moreover imagine you have a simple table:

| project name | project description |

there are 100 rows out of which every description is wikified. that 
means 1 generator for the template and 1 for each description. Total 101 
  generators invoked. Neat.

> 
>> <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.
${project.description as radeox-string} would be any better?

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

The dynamic tags in my use case are used for data injection. Could be as 
well rendered by a stylesheet and just as in previous cases I won't do 
it for reasons I outlined above.

My regards

PS. Please do not take is as fighting back. Out of my small experiences 
these are real use cases where I needed convertors and advanced macros 
badly. If I am wrong just show me a better way.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
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

Mime
View raw message