Hi All,
It looks like we're roughly finished with getting POI (minus the Cocoon
stuff) on Jakarta. It looks like we've all decided to do an interim POI
production release (1.5) ASAP so that we capture a few bugfixes, minor
enhancements, and the new packaging. We'll go live whenever Sam gets
time to set up our site build.
Now that all that stuff is basically done (but never *finished*) I'm
working on the POI::HSSF Serializer transition to Cocoon. In order to
do this properly I'd like to elicit your advice and consent.
Here are the pieces and my first thoughts on where they might go, please
take a gander and tell me where I'm wrong or any suggestions you might
have.
I've also got a grand *question* at the end. I really appreciate the
help on both of these issues.
convention: if the subpackage isn't mentioned it goes under its parent
(or I missed it ;-) ).
--------------------------------------------------------------------------
the current -> the new home in cocoon.
(moves to)
net.sourceforge.poi.serialization.HSSFSerializer->
org.apache.cocoon.serialization.HSSFSerializer
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poi/poi/production/src/net/sourceforge/poi/serialization/
---------------------------------------------------------------------------
net.sourceforge.poi.xml ->
org.apache.cocoon.serialization.poi.hssf.elements
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poi/poi/production/src/net/sourceforge/poi/xml/
These classes handle specific elements. I realize the structure is
somewhat different then other serializers, but it makes it incredibly.
Try not to knee-jerk react to this like I did. I was like "Whoa..dude
that's too many classes.", but then the elegant nature of Marc's design
grew on me. After working with it a bit I realized how easy it makes
implementing new features/elements.
-----------------------------------------------------------------------------
net.sourceforge.poi.cocoon.serialization.elementprocessor->
org.apache.cocoon.serialization.poi.elements
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poi/poi/production/src/net/sourceforge/poi/cocoon/serialization/elementprocessor/
These classes will be useful for ALL POI serializers and might be useful
for other serializers as well, but I'll leave that alone at the moment.
-----------------------------------------------------------------------------
net.sourceforge.poi.cocoon.serialization.util->
org.apache.cocoon.serialization.poi.util
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poi/poi/production/src/net/sourceforge/poi/cocoon/serialization/util/
-----------------------------------------------------------------------------
net.sourceforge.poi.serialization.hssf ->
org.apache.cocoon.serialization.poi.hssf
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poi/poi/production/src/net/sourceforge/poi/serialization/hssf/
-----------------------------------------------------------------------------
net.sourceforge.poi.serialization.poifs->
org.apache.cocoon.serialization.poi.poifs
These classes are useful for any serializer based upon the POIFS
filesystem (our impl of ole 2 compound document format)
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poi/poi/production/src/net/sourceforge/poi/serialization/poifs/
-----------------------------------------------------------------------------
Excuse the mess that the old packages were in. I think its hard to get
it right the first two times.
Okay now the big question. I've started on the Generator for HSSF, but
I've got a bit of a design dilemma. We already have an "event-based
API" for reading
(http://cvs.apache.org/viewcvs/jakarta-poi/src/java/org/apache/poi/hssf/eventmodel/ &
http://cvs.apache.org/viewcvs/jakarta-poi/src/documentation/xdocs/hssf/how-to.xml for
more info) in XLS files and throwing events.
My question is, should the generator have its own set of elements (which
would implement HSSFListener or contain members called by an
HSSFListener), or should the elements from the serializer be shared with
the generator (possibly having their own HSSFListener member or
implementing it).
The issue being, while they share fields and are on the common subject
of supporting the XML elements, they do not share functional lines in
that one is essentially output and one is input.
I've been swinging back and forth on this and decided I should try just
asking the experts.
I realize the above is a lot to take in at once. I greatly appreciate
any help or advice rendered. Once I get the requisite feedback,
discussion and consent, I'll correlate the input and submit a final plan
and put it on a URL for final approval. Then I'll stage these at the
current sourceforge site, probably complete with cocoon, get it working
and building properly and lastly submit the patches for commit. Then we
port word doc format to Java... *yawn* no sweat ;-)
Thanks for the help,
Andy
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
