cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <john.r.morri...@ntlworld.com>
Subject RE: POI Serialization code committed
Date Fri, 08 Mar 2002 03:50:55 GMT
Do we have sufficient code &/ reason for a separate
Cocoon-contrib cvs?

J.

> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: Thursday, 07 March 2002 10:06 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: POI Serialization code committed
>
>
>
> 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.
>
> 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).
>
> Giacomo
>
> On Thu, 7 Mar 2002, Sylvain Wallez wrote:
>
> > acoliver wrote:
> >
> > >>That's really cool stuff, however I have some wonders about the source
> > >>code that's been added to the Cocoon CVS :
> > >>
> > >
> > >This comes to me as a surprise; AFAIK it was unanimously voted
> upon like 2
> > >months ago.
> > >
> > What was voted in january was (taken back from the archives) "Would you
> > like the cocoon-specific POI code to be hosted in the Cocoon CVS and
> > shipped with the next distribution (along with the POI library in the
> > /lib directory)?".
> >
> > My answer to this question is +1. The goals of POI are great and having
> > POI integrated with Cocoon is a must have. The problem comes from what
> > we respectively understand by "cocoon-specific POI code". For all other
> > components that Cocoon integrates with, this means a few glue classes.
> > For POI, there are about 100 classes modelling the contents of a
> > spreadsheet ! What the hell does this have to do with Cocoon ?
> >
> > >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().
> >
> > >>- shouldn't all the ElementProcessor stuff be better located in the
> > >>POI > CVS repository ?
> > >>
> > >
> > >I don't think so.  XML processing is outside the scope of POI,
> and besides,
> > >the elementprocessor is a generic Avalon Component framework
> for element
> > >processing that can be used by other Serializers.
> > >
> > I was talking about what's in elementprocessor.impl.poi.* : I agree
> > about the ElementProcessor framework. This is a generic thing that could
> > well go into xml-commons or jakarta-commons for a wider use.
> >
> > >>- is Cocoon the only product in which serializing XML to XLS
> is usefull ?
> > >>
> > >Cocoon is the only one I'm aware of, but I can't rule this
> out, of course.
> > >
> > Are you really serious ???? I can't agree with that : many people use
> > XML without Cocoon (even if we may consider it a bad choice ;). And how
> > many projects are there in Apache that deal with XML and could benefit
> > of a POI serializer ?
> >
> > >
> > >These classes were specifically written for Cocoon, they would
> need rework
> > >since they are hosted as a Component.
> > >
> > I checked the "Avalonization" : one implementation of Component, and 4
> > classes using getLogger(). C'mon, let's get serious ! For serialization,
> > the only interface that's really needed by Cocoon is
> > org.xml.sax.ContentHandler. Is it Cocoon or Avalon specific ?
> >
> > >
> > >They have nothing to do with any of the existing POI APIs,
> they merely use them.
> > >
> > ... and Cocoon doesn't have anything to do with a spreadsheet class
> > model, as it deals with XML and XML-aware components. Honestly, these
> > classes are more POI's concern than Cocoon's one.
> >
> > >>From what I can see, all classes in
> > >>components.elementprocessor.impl.poi.* are really POI-specific and can
> > >>be understood and maintained only by people with POI knowledge. So why
> > >>aren't they managed by the POI project itself and delivered
> in poi.jar ?
> > >>
> > >
> > >Well, they have nothing to do with the POI project at large. They were
> > >written just so Cocoon could serialize an XML tag language (we
> picked one
> > >for Cocoon) to XLS.  We picked one that we thought was the
> nicest and most
> > >widely availabe.
> > >
> > >I don't think you really need any POI knowledge if you'd like to help.
> > >The POI::HSSF API is really simple and furthermore those classes are
> > >documented not only through javadoc but the Gnumeric
> > >(http://www.gnome.org/projects/gnumeric/) XML Schema that POI
> committer Marc
> > >Johnson donated, as well as the DTD.
> > >
> > Well, you're saying here that XML is a concern of the POI team ;)
> >
> > Don't you think XML import/export could be a real added value to the POI
> > project ? Hiding this feature in Cocoon goes against an increased use of
> > POI.
> >
> > >>The strength of Cocoon is its ability to integrate many components
> > >>(XIndice, JFor, FOP, Velocity, to mention a few). But IMO, it should
> > >>only host "glue" classes for these components and not the components
> > >>themselves.
> > >>
> > >
> > >Ahh I think you're thinking the POI project has something to
> do with XML or
> > >templates, but it does not. It's a Java API and implementation
> project to
> > >read-write legacy formats, not to do *conversions*.
> > >
> > I'm not talking about templates at all. But yes, I think it would be
> > good for POI to allow conversion between XML and legacy format.
> >
> > >>From a project management point of view, we have the danger
> for part of
> > >>the traffic on cocoon lists being related to POI, which means
> noise for
> > >>Cocoon and loss of information for POI, and lots of
> POI-related entries
> > >>in Bugzilla (user reports and patches from the POI team).
> > >>
> > >
> > >Currently, traffic on the Cocoon lists related to XML
> Serialization of XLS.
> > >IMHO the problem you envision is identical to the ones Cocoon
> has with other
> > >projects it uses.
> > >
> > I disagree. When posts are related to projects integrated with Cocoon,
> > either the answer is simple and given as a reply, either people are
> > directed to the respective mailing lists of these projects. With the
> > serialization stuff, I envision many questions like "Andy, are you
> > listening ?" (and will you be listening, since POI doesn't care about
> > XML ?) or "Ask to poi-dev, they will send us a patch".
> >
> > >>So, what do you think about moving (back ?) the ElementProcessor stuff
> > >>to the POI CVS, and keep only the Serializers in Cocoon CVS ?
> > >>
> > >
> > >I consider these to be part of the serializer to be honest.
> It has nothing
> > >to do with anything else in POI.  I really don't want to host interface
> > >classes to all the projects we provide POI functionality that
> have nothing
> > >to do with POI.  That would be kind of messy.  I mean, I'll soon be
> > >developing MIME mappings and interfaces between POI and Lucene
> and I really
> > >don't want those to live in POI either (even though some will
> be specific to
> > >using POI from Lucene).
> > >
> > Damn ! So the aim of POI is to flood in ("pollute" came to my mind) all
> > projects that want to integrate it, even if this integration relies on
> > well-established standards like SAX and MIME ? Sorry, I can't be happy
> > with this. There are other ways to promote POI. Having builtin XML
> > support is IMHO one of these.
> >
> > >
> > > The scope of POI seeks to be really small and focused: Java
> ports of OLE 2
> > >Compound Document based file formats.  We have no XML classes nor do I
> > >really want any there.
> > >
> > XML is now a dominant technology in the software arena, because it moves
> > software development from sequential logic to data transformation. And
> > reading/writing legacy formats *is* data transformation.
> >
> > Don't you have great ambitions for your baby ? Announcing
> > XML<->Word/Excel roundtrip support in POI is likely to attract _a lot_
> > of people. A lot more than just a Java API.
> >
> > >
> > >If you deem this unfit for Cocoon is there an XML project somewhere for
> > >Cocoon Serializer tag implementations?
> > >It seems that there is a need of making a project that
> converts file formats
> > >in xml.
> > >
> > As said above, there may be room for the ElementProcessor framework in
> > [xml|jakarta]-commons. Cocoon could use it, but other projects as well.
> >
> > >
> > >What do you think?
> > >
> > You've read it inline ;)
> >
> > >
> > >-Andy
> > >
> > Sylvain
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message