cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: XML input module (was: RE: Nice changes!)
Date Wed, 02 Oct 2002 07:13:45 GMT
On 01.Oct.2002 -- 04:09 PM, Hunsberger, Peter wrote:
> > Think of the various matchers and selectors in cocoon. What if you
> > could just plug-in the data source? There wouldn't be sources * match
> > type matchers.
> This gets me to a pet issue of mine:  If I ever get the time I'd really like
> to build a version of the site map pipeline handler based XSLT that has all
> context information available to it as XML; the request variables, session
> data, etc.   The XSLT could either act as a filter to some SAX event handler
> or you could use XSLT extensions to invoke the Cocoon components directly or
> you could use some form of import mechanism to invoke the Cocoon components.
> 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. 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

> that invokes other transforms.  As such, XSLT import semantics might be a
> reasonable way to go, but I doubt you could use them in native form since
> some Cocoon components seem orthogonal to the transform process?  However,
> for the normal case you might have to instantiate parsing and transformation
> 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.

> But none of this has any advantage over examining the same data in an XML
> 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.


> Yes, that certainly makes sense, you're extending the sitemap capabilities
> to build in some of the capabilities of XSLT: but just the XPath portion.  I
> guess what I'd rather see (now that I understand what you're trying to do),
> is a sitemap pipeline parser that was XSLT transform driven (user definable
> of course).  It likely wouldn't replace all of the sitemap, but rather would
> be aimed at replacing just the pipeline handling.  Ultimately my reason for
> doing this is that the sitemap pipeline (as it exists today) ends up
> encoding a lot of business and presentation rules.  I want to have these
> rules be configurable from a database (of some form).  As such, I want to be
> able to generate XML (from my database) that invokes rules, which are
> written in XSLT.  You're getting a long way there, but XPath by itself isn't
> sufficient for all types of rule handling.

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

> > XSP is completely absent from this picture. Actually, there's no
> > support to use it from XSP as of today.
> If I understand you're essentially creating many components reusable from
> the pipeline and trying to have a single set of semantics to extract data
> from these components into the pipeline?  I'd guess the XSP folks would want
> 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. It would not be much of a problem to make it
accessible from XSP as well. It's just not done, yet.

C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

View raw message