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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
