You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2002/02/05 02:11:57 UTC
HSSF Serializer structuring within Cocoon.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: HSSF Serializer structuring within Cocoon.
Posted by Stefano Mazzocchi <st...@apache.org>.
"Andrew C. Oliver" wrote:
>
> 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.
awesome!
> 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.
ok
> 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.
Hmmm, question: could POI become a component and have both Generators
and Serializers use it?
This is because I don't like having so many classes into the
'org.apache.cocoon.serialization' package, expecially having .poi.utils.
sounds wrong to me... it screams for a more 'component oriented'
refactoring.
What do you people think?
> 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).
I think sharing the most is the way to go since this would ease
componentization. But don't do it if you find this overkill (I can't
judge it now since my internal POI knowledge is close to zero and I
don't have time to change this in a short period)
> 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.
Yes, this is good point.
> I've been swinging back and forth on this and decided I should try just
> asking the experts.
Think in terms of componentization (follow the Avalon patterns) and
things will clear out in your mind.
> 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 ;-)
:) hope this helped.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org