Back to Basic, or flowscript actually
Doing (complex) eventcached DASL queries without the HippoJX generator can be a tedious task.
Clearly, the Cocoon Jxtemplate generator is a nice mechanism for a) passing sitemap parameters into the query and/or b) changing the semantics of the query based on the paramters values, but since it doesn't handle caching natively, the programmer has to use flowscript to create a custom cache-key from sitemap parameters and pass it into the Jxtemplate, together with a NOPValidity object. This means 2 matchers for every DASL (since most DASL's require custom parameters) and a lot of extra work == bad!
So we created the HippoJX generator which produces cache-keys automatically from the sitemap parameters passed to it, and always uses a SourceValidity. We can even specify what parameters should/shouldn't be used in the cache-key!
I've been updating an existing website still using the old flowscript->dasl scheme, to the new HippoJx solution, and found it very usefull and easy to set up.
Untill.. I had to use a java.util.StringTokenizer inside my JXtemplate.
(from cocoon-dev discussion 'Java objects in JX templates')
packages, classes, constructors, static methods, constants is available in jxtg via rhino ... Unfortunatelly in 2.1.x those variables are only properly initialized when flowscript is the controller. 2.2 artificialy creates those variables no matter if you already have rhino context available or not.One more thing: this construct ${java.util.StringTokenizer(items, delims)} will work only when .jx is invoked from flow. This is due to the fact that neither JEXL nor JXPath is able to reference packages/create java
objects. The functionality in fact is provided by Rhino library.This is already fixed for 2.2-dev (still the dependency on Rhino remains).
So I gues I'm back to wrapping (some) of my DASL call's with flowscript again, untill 2.2 is released..