cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
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).

Yup.

> 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

>
> >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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message