cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corin Moss" <>
Subject RE: [RT] since we are at it, more irons in the template fire: Xenon
Date Wed, 08 Dec 2004 21:03:04 GMT

Hi All,

I suspect as this topic is discussed more and more we'll find that many
people within the Cocoon community have implemented their own templating
/ view model.  Like Peter, we're using a model based on "filters" -
which are basically dynamically evaluated XPath fragments.  The document
which holds these fragments is called a "skin".  The filters are
contained within the markup document to be used as the skeleton for the
final output.  

This approach has a couple of advantages:

1.  It only operates on the data given it - so there's not a lot of
point in trying to mangle it to produce SQL results
2.  People writing skins don't need to know the ins and outs of XSLT -
the majority of what they involves simple XPath statements.

The approach we have taken is as follows:

Data Access -> RDF (XML) Document generated
             |            |
            Skin        Data
Document Aggregated (including Skin and Data)
          XSLT document applied

In our case the same mechanism is used for generating both skin and data
component (although for the purposes of this discussion that's not
really important.)   Xalan is used as the engine for applying the skin's
XPath components to the data set provided it.  We do this dynamic
evaluation by using (unsurprisingly) the dyn:map XSLT extension.

The XSLT document which performs this evaluation is surprisingly small
(about 200 lines - including a huge number of comments ;)

>From our perspective this approach gives us all the SOC we need.  Having
said that, Java calls can still be made (and sometimes are) but these
calls operate solely on the data available and don't really encapsulate
business logic - they're more calls of convenience.

We've been using this model in production for over a year now on an
interesting variety of platforms (including Teletext). The majority of
the development is being done by web developers with little or no XSLT

If there's interest, I'd be happy to provide an example of a skin / data
aggregated document.


-----Original Message-----
From: Peter Hunsberger []
Sent: Thursday, 9 December 2004 9:27 a.m.
Cc: SIMILE General
Subject: Re: [RT] since we are at it, more irons in the template fire:

On Wed, 08 Dec 2004 12:10:09 -0500, Stefano Mazzocchi
<> wrote:

> Now, let me tell you a story about templates.

As the sound of the theme music from Beverly Hillbillies rises in the


> I like the name (and the concept) of lenses.
> We have identified the need to have "isolated and reusable
> programmatic artifacts that know how to transform something into SAX
> events". They were named 'taglib' because the syntax normally used to
> identify them is a namespaced element (a 'tag').
> The problem with the name is that it has been used (and abused!) in
> too many systems and brings memories of abuse and FS. Like the
> infamous <if> tag (also abused by XSLT)
> I think we should call our CTemplates taglibs "lenses" instead.

For our internal templating system we're currently implementing a
concept we call "filters" that lets one declaratively define conditional
portions of a template/view.  As I read your story (:-) I kept thinking
that lenses and filters lined up pretty much the same.
Then I jumped over to the Xenon description and found a "xe:filter" as
part of the lens description.  I won't have time to dissect everything
completely, but semantically a lens as used in Xenon seems to be a
filter (and filters as used in Xenon seem to be conditionals).  If so, I
think the idea makes perfect sense, at least for our system

However, I'm not quite sure that the lens concept maps exactly to
everything that is being discussed WRT Cocoon?  In particular, there
seems to be more of a active modifier role (ie "turn something into SAX
events") to what people are looking for for Cocoon?  Then again, maybe
that's part of the problem and why you like the name "lens"?

I'll also note that if you take the optical analogy literally, you want
both lenses and filters working together as separate components and not
mixed together the way Xenon seems to do.  I wonder if there's some SOC
in the view model that really remains to be completely abstracted?  I'm
not sure "lens" is an abstraction I find completely understandable...

Peter Hunsberger

CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at

View raw message