cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [OT]Re: [RT] How scripting made me hate java
Date Tue, 22 Feb 2005 16:29:23 GMT
On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi
<> 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

View raw message