cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: POI Serialization code committed
Date Sat, 09 Mar 2002 14:31:42 GMT
On Fri, 8 Mar 2002, Sylvain Wallez wrote:

> giacomo wrote:
> >As always when Sylvain gets engadged he has very good arguments which
> >convinced me to support moving thoes classes out of Cocoon and only
> >leave the serializer and Avalon component glue code in Cocoon's CVS.
> >
> Thanks, Giacomo. I value your judgment as you are one of the Cocoon
> "wise men".

Boy, that sound like I'm an old man :)

> >We have to see where the other code will best fit into other project (if
> >the POI team cannot be convinced to hold it in their CVS).
> >
> We should do our best to convince them that XML support in POI is a good
> thing for the project (I've given a lot of reasons for that).


> One of their objectives seems to keep the library as small as possible.
> To achieve this, they could package the XML stuff in a separate jar
> (poi-xml.jar) so that people can use only poi.jar if they don't care
> about XML.

Seems a valuable way to go for them.

Any comments from the POI side?


> >Giacomo
> >
> >On Thu, 7 Mar 2002, Sylvain Wallez wrote:
> >
> >>acoliver wrote:
> >>
> <snip/>
> >>>The package names were cross referenced with the location in the previous
> >>>CVS.  The only thing that has changed was the Avalonization of the
> >>>serializers which Stefano and others proposed.
> >>>
> >>I checked the Avalonization : one implementation of Component and 4
> >>classes using getLogger().
> >>
> Having thought deeper about the componentization of the serialization
> stuff, I think that it doesn't really need to be a Component :
> HSSFElementProcessorFactory doesn't use any of Avalon lifecycle
> interfaces, and the only class using it is HSSFSerializer, which, as its
> name implies, is obviously tied to this particular implementation of the
> ElementProcessorFactory interface.
> As all serializers, HSSFSerializer *is* a component and declared as such
> in the sitemap. But just as we don't have a "FOPProcessor" component
> used solely by the FOPSerializer, we don't need a new component used
> solely by HSSFSerializer.
> Not every class needs to be a component, and adding too many entries in
> cocoon.xconf will be confusing for users. So what about the
> "de-Avalonization" of the ElementProcessor (which means remove a useless
> Component implementation and an entry in cocoon.xconf) ? Or did I miss
> something that really requires it to be a component ?
> <snip what="long discussion"/>
> Sylvain

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

View raw message