>> 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.
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 JSCocoon.java). 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 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. 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 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. 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 clear! > 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 evil. > > 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. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
