cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: XML input module (was: RE: Nice changes!)
Date Wed, 02 Oct 2002 14:47:34 GMT
>> This gets me to a pet issue of mine:  If I ever get the time I'd really
>> to build a version of the site map pipeline handler based XSLT that has
>> context information available to it as XML; the request variables,
>> data, etc.   The XSLT could either act as a filter to some SAX event
>> or you could use XSLT extensions to invoke the Cocoon components directly
>> you could use some form of import mechanism to invoke the Cocoon
>> The first is perhaps more pure to XSLT, but it could have strange
>> transformation/filtering requirements and be a little opaque to those not
>> comfortable with XSLT ;-) More on imports in a moment...
> Well, go ahead: use the request generator - I think there is no
> session generator &c., otherwise you could aggregate the other context
> information together - and you are almost done. 

IIRC the session generator as it exists today is pretty limited, you can
basically tell it to retrieve specific name value pairs.  One could attempt
to code a more generic version that ran all session objects using
introspection to find toString methods, getters, etc. You could also make it
understand collections and maps and handle them in some reasonable way.
However, given that you can shove anything into session it's not likely that
one can always have a generic session handler that will do exactly what
everyone wants. 

This is likely an issue you're going to run into also; mapping XPath to
random session objects might be possible, but I suspect the two domains
aren't perfectly isomorphic :-(

> Add some methods to
> access sitemap components (actions only, I guess - you could copy them
> from the sitemap implementation or This is probably
> limited to produce XML (i.e. well-formed content, no binaries), but
> hey!

Generators would sort of be implied; they'd be dependant on how you set
up/configured the context handling.  It seems to me that some method of auto
config file recognization similar to what Tomcat uses might be nice to pick
up generators.  Add a generator.xml to the appropriate directory and the
generator gets invoked.  (No real advantage over the current sitemap except
a little more modular).

One could still spit out anything that XSLT can subsequently be serialized
by other Cocoon components (eg. the text XSLT output methods).  Moreover,
one could spit out binaries via extensions or custom serializers.  Not sure
you'd want to do that, but I can't see what would stop you from doing so?

> > As such, XSLT import semantics might be a
> > reasonable way to go, but I doubt you could use them in native form
> > some Cocoon components seem orthogonal to the transform process?
> > for the normal case you might have to instantiate parsing and
> > many fewer times.  
> I can't judge this one. I feel that it should not be a real problem,
> especially since those components might be of little use in your
> scenario anyway.

Probably true, I'm trying to drive a lot of the site map and Java into pure
XML and pure XSLT (well as pure as I can get it).  As such, some of the
components that Cocoon currently has would end up being replaced by a
library of XSLTs instead of a library of Java components and you wouldn't
need to invoke them in the way they are currently handled.

> > But none of this has any advantage over examining the same data in an
> > tree via XSLT?
> No, it's just that it is usable in places where there's no XSLT
> available, the data is no XML or the data is very small.

Ahh, but if I get my way you'll always have XSLT available and you'll almost
always be able to represent your data as XML :-)  However, whether it's
worth invoking such a complex beast for handling tiny amounts of data isn't

> So, maybe you like the flow idea better? In 2.1-dev you can code your
> business logic in javascript. But even there it is handy to have this :-)

At first I thought flowmaps would be what I want and that was part of my
reason for joning the dev list; I wanted to see where Cocoon was heading in
this regard.  However, you can count me in the camp that more-or-less
considers JavaScript an abomination that should have never been foisted upon
unsuspecting web developers.  I use it, but only because it's a necessary

> > If I understand you're essentially creating many components reusable
> > the pipeline and trying to have a single set of semantics to extract
> > from these components into the pipeline?  I'd guess the XSP folks would
> > similar capabilities, but I can see why that's not your concern!
> Yes, but not just the pipeline but anywhere. Actions use it, so do
> Matchers and Selectors. 

No more matchers, no more selectors; just XSLT templates ;-)...  Seriously,
once (if?) XSLT 2 gains regex capabilities I can't really see why a pure
XSLT pipeline couldn't do everything that matchers and selectors do, therby
eliminating huge chunks of the current Cocoon code base?

To unsubscribe, e-mail:
For additional commands, email:

View raw message