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.
The Overcomponentization is a big problem. Unless we start keeping an
eye on it now, we will *never* get around to fixing it.
>
> 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.
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.
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.
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
