cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Date Sat, 13 Apr 2002 12:06:53 GMT
On Fri, 12 Apr 2002, Berin Loritsch wrote:

> Stefano Mazzocchi wrote:
> > Berin Loritsch wrote:
> >
> >>Coming to a theater near you, Cocoon 2.1: Same Plot, Different Story!
> >
> >
> > Oh, I love it, love it, love it. :)
> >
> > Now, let's get nasty! how about XSLT-transforming the sitemap into Jon
> > Bosak Play DTD :)
> I'm not familiar with Jon Bosak :(
> >
> > A sidenote: I'm pretty sure that everybody was laughing so loud that all
> > your points about refactorization was not really taken seriouly.
> Probably, but it was an example of analyzing Cocoon with the "Play"
> analogy that I was introduced to in Avalon.
> >
> > But I think Berin touches a few serious design issues
> > (overcomponentization, role of cache control, component isolation) that
> > we must seriously consider.
> Those are the biggest beefs I have with Cocoon right now.  In my view of
> the world, the existences of a Cache should be invisible to the anybody
> who is not specifically tuning it.  We should notice its existence
> solely by the virtue of our page loads being faster.

Ehm.. the cache is almost transparent for a user now (the exception is
XSP). If you work with XML, XSLT only you'll never get in touch with
cache aspects, or do I missed something?

> The Overcomponentization is a big problem.  Unless we start keeping an
> eye on it now, we will *never* get around to fixing it.

Yes, this is true. We should separate the sources into smaller pieces
and hopefully see where those components are which can be rewritten as
either helper/utility classes or maybe even merge them with others.

> > I only think that if we do this for 2.1 it will take forever for us to
> > reach a final release... this is the reason why I was considering
> > componentization refactoring to happen for 2.2 at least.
> >
> > What do you think?
> >
> I'm not saying we should go through and implement the COcoon
> Application COmponentarchitecture now.  I am saying we need to quell any
> further unnecessary componentization as we are now busting at the seams.
> What I would like to see is that all _optional_ components be broken out
> into little "mini" projects with their associated classes all in one
> place.  Kind of like what we recently did with Excalibur.  In fact, when
> we finally get the bugs worked out of the dependancy system, I'm sure
> you can adopt the recursive dependancy build system in Excalibur for the
> Cocoon components.

Not even the optional component. I can see that we split up the source
using the following approach (as a first step):


 1) Break out everything that make the o.a.c.Cocoon class compile into
the core package.

 2) Isolate the different environments into a sub tree. I mean
separating the servlet environment from the cli environment can reduce
the size of a deployed Cocoon for the intended use. So Avalon and other
projects which build their site and docs using Cocoon don't need a
servlet environment. Those which use Cocoon in a servlet env don't need
the cli stuff.

 3) Start separating out some very basic sitemap component
implementation (like the Reader, FileGenerator, XMLSerializer) to
finally enable testing the stuff from 1) and 2).

 4) Start separating other components. One way could be to separate
components based on the optional jar list (FOP components, DELI
components, Lucene components, Velocity components, etc.)

I'm sure the steps above will be repeated in cycles to beak out the
right stuff but could lead to clearly (or at least better) separate

> That way, the _only_ thing in the cocoon.jar is the core essential
> Cocoon components.  All things optional are in separate jars so that we
> can create an install that is minimalist.

Yes, see above for a way to go into that direction.

> Another thing that it allows us to do is start considering the role of
> the sitemap in regards to dynamic loading of jars.  We currently let the
> servlet engine load all jars associated with a webapp.  If we want true
> pluggability, we need to let subsitemaps load their own set of jars so
> that we can have true component isolation.  Also, so that when we come
> up with the formal Cocoon Application ComponenT Infrastructure (CACTI?)
> or whatever we call it, we also have the component loading
> infrastructure in place.

Exactly, this has beed discussed by Stefano and me when he was here at
my place two weeks ago. I think that the Cocoon core must be able to
build a ClassLoader instatiated with the set of jars described in the
yet to be defined Cocoon Block Descriptor Language (CBDL) for each
Cocoon Block. There is the need to have a ComponentManager to be build
up with the components mentioned in the Cocoon Block Description (CBD)
for private components for each Cocoon Block as well.

For the exported components of the deployed Cocoon Blocks I see two
ways of making them available to the other Cocoon Blocks:

 1) Have a root CM populated with the exported components from each
Cocoon Block.

 2) Populate the CM for each Cocoon Block with components the Cocoon
Block in question depoends on.

In 1) we choose a lazy way of collection all available components into
one CM. The approach in 2) makes access to components possible exactly
as mentioned in the CBD for the block.

> I don't think that is unreasonable.  It is a good first step toward the
> componentization process, allowing us to attack one aspect of it and
> provide some real feedback before we add in the application component
> infrastructure.

I think it may be a plan to go further.


To unsubscribe, e-mail:
For additional commands, email:

View raw message