cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Cocoon2] XSP 2.0 changes list
Date Mon, 22 May 2000 22:32:15 GMT
Jonathan Stimmel wrote:
> On Mon, May 22, 2000 at 08:27:34PM +0100, Paul Russell wrote:
> > On Mon, May 22, 2000 at 01:58:25PM -0400, Donald Ball wrote:
> > > > 6) Taglib creation kit
> > > >
> > > > This to simplify the creation of taglibs.
> > >
> > > ha! would love to see it, but i don't see it happening.
> >
> > Heh. Cynic ;)
> >
> > Stefano: What exactly did you intend this to comprise?
> > I *guess* it would be kindof the XSP 'SDK'...
> I'd like to see this too, but haven't actually started on it yet. I
> envision a taglib processor, which could handle the processing of
> multiple taglibs in a single pass of a document, and which would be
> responsible for the handling of the namespaces (the few taglibs I've
> seen are all hardcoded for a given namespace). Also, from what I've
> seen, taglibs need to be specified in the cocoon configuration file
> (at least, I think they did in cocoon1). This alone has caused me
> to shy away from playing with them (since getting our ISP to make
> configuration changes is rarley a pleasant experience :-/)

These are all good points.

1) avoid configuration changes for taglib usage: this has been solved
with the advent of <xsp:logicsheet> which will allow you to map a
logicsheet to a particular namespace in your own page without requiring
any change in the main configuration.

2) namespace processing: some time ago I proposed the introduction of
the <xsp:namespace> tag to allow content to be automatically transformed
in that namespace without requiring taglibs to provide direct hooks for
such facilities.

I spent a good half an hour today, thinking about this. And I came to
the conclusion that I'm not sure this is a good idea. Let's see why:

there are two possible cases:

 1) elements are declared statically

     <xsp:namespace prefix="my" uri="">
      <date>is <xsp:expr>today</xsp:expr></date>

  should generate

     <my:date xmlns:my="">Today is May 23 2000</my:date>

 2) elements are constructed dynamically

     <xsp:namespace prefix="my" uri="">
      <sql:query>select * from mystuff</sql:query>

   should generate

     <my:mystuff xmlns:my="">

In the first case, <xsp:namespace> is nothing different from declaring
the right namespace, since the XSP engine is supposed to let the
namespace declarations be copied over if they don't map to taglibs and
are not expanded.

The useful case is the second.

The problem is: how is this implemented? Possible solutions are:

1) every taglib exposes a sort of API to allow the XSP engine to "push"
the right namespace for the dynamically generated elements/attributes.

2) the compiled page "filters" the SAX events generated by the taglib at
runtime and does an inlined namespace addiction.

Both could work, but while the first is no different from letting each
taglib define its own way to do namespaces (well, right, probably a
standard way it's better anyway, given the importance of namespaces),
the second would reduce performance and go against the paradigm of page

So I'm stuck and since Ricardo wants to rewrite the taglib hooks for
simplifying their creation, I think that adding more impositions on
namespaces and such wouldn't help... but I can't really tell until I see
what he has in mind for them.

Ricardo, anything to elaborate on this?
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message