On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > Wojciech Gdela wrote: > > Hello, > > <sni>OO pipeline discussion (sorta)</snip>
> It's also true that we know a lot more than pipeline caching is more a > myth than a real useful thing, at times and more so in complex web > applications. Hmm, I wouldn't say that, it's just hard to do well: you end up having to break down every different level of data provider into it's own generator or source and having some kind of complex cache invalidation that can walk orthogonally across the validity objects for these generators/sources. Having more-or-less completed this for our app I can say we get definite performance benefits. If I had time I'd like to comment more, but basically we ended up building a sort of miniature (3 table) relational database in memory to manage the cache (maps many screens to many data sources). Sources register invalidation event handlers within it by "invalidation key type". Invalidation keys can determine if they match a particular event (which passes in a candidate key) and if they do they blow away the validity. Different types of keys can decide whether they care about other types of keys and to what extent (complete equality, partial equality, etc.) That way we get out of the hassle of trying to inter-relate every sources dependencies with every other source in some kind of complex graph. Under this scheme we no longer use the Cocoon sitemap for matching, pretty much everything is a single generic Cocoon generator. We then use Java based lookups (a factory pattern into our EJB layer) to determine the sources for various requests. So basically, we already have an existence proof that you can have dynamic pipeline construction and caching living in coexistence within Cocoon. > Am I ready to surrender to 'dynamic pipelines'? not yet, but I'm ready > to admit that we know better today and given what cocoon has become, it > might open the door to even better innovation. > > So, I welcome RTs on the topic of the 'unification' of sitemap + flow > into a 'cocoonscript' that has SAX pipelines as native constructs, even > if I urge people to realize that sitemaps will have to be supported for > a long time in the future, given our user base. Well, you may recall my old push for an XSLT based sitemap.... Still think it would be conceptually a good way of doing this, but it seems pretty obvious that what people want is something more script like and not more XSLT! Given that, having a way to configure component declarations (in an XML sitemap type thing) that are then only referenced/matched in some kind of flowscript like language (taking the sitemap pipelines out of the picture) seems natural? Eg, prebuilt Javascript pipeline objects. If you want to do this in Java, then really, source resolvers already give you (more-or-less) the Cocoon way of doing this... -- Peter Hunsberger
