cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <ekst...@ibg.uu.se>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Fri, 03 Dec 2004 02:48:27 GMT
On Thu, 2004-12-02 at 16:47 -0500, Stefano Mazzocchi wrote:
snip...
> In both cases, they are suboptimal from what I wrote above, where 
> content population and content presentation are kept completely isolated 
> and the only contract between the two is:
> 
>   1) the shape of the objects in the context
>   2) how to perform simple variable espansion, list iteration and 
> conditioning.
> 
> #2 is the only thing that should be exposed to a template language (just 
> like velocity does), everything else should be dealt with at the view 
> population level. Which is going to be code, written by coders and 
> people that deal a lot better with code than with anything else.

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.

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

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. 

Cheers Jonas



Mime
View raw message