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 :(
Oh, God! Jon Bosak is the guys who started the XML thing, the 'father of
XML' so to speak. Ask Google :)
> >
> > 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.
:) I remember the night when Federico and I came out with that metaphor
to explain it to Pier. Gosh, I wonder what we could do now if we were
all still living in the same city :(
> >
> > 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.
Oh, yes, SoC at last.
But tell me: where do you see the problem with this approach? I normally
don't have to do anything on my cache and it's pretty transparent to me.
> The Overcomponentization is a big problem. Unless we start keeping an
> eye on it now, we will *never* get around to fixing it.
I wouldn't be that drastic, but I agree that Cocoon suffers from
overcomponentization (but it's really hard to balance things out the
first time so I'm not that worried, look how many years it took us to
get Avalon right enough to be useable).
> >
> > 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.
Agreed.
> 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.
Hmmm, interesting, sounds much like what Ovidiu was proposing... but I
think this goes so close of the refactorization what we'll need to
perform for blocks that I restate that I wouldn't want to do it twice.
> 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.
I don't think there is anybody against this, Berin, we are just trying
to find the best and more future-proof way to do this
refactoring/recomponentization
..
> 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.
Again, read my proposal on Cocoon Blocks and you'll see that the entire
CACTI that you proposed is already included in that design.
> 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 say we do both at once, since they more or less require the same
machinery.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
