cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: HSSF Serializer structuring within Cocoon.
Date Tue, 05 Feb 2002 15:21:52 GMT
"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.


> 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
> ---------------------------------------------------------------------------
> net.sourceforge.poi.xml ->
> org.apache.cocoon.serialization.poi.hssf.elements
> 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
> 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
> -----------------------------------------------------------------------------
> net.sourceforge.poi.serialization.hssf ->
> org.apache.cocoon.serialization.poi.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)
> -----------------------------------------------------------------------------
> 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'

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
> ( & 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.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message