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 JSCocoon.java). This is probably
limited to produce XML (i.e. well-formed content, no binaries), but
hey!
[...]
> 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.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
