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): core/ environment/ servlet/ cli/ components/ ... 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 things. > 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. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
