cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoliver <acoli...@nc.rr.com>
Subject Re: Re: HSSF Serializer structuring within Cocoon.
Date Tue, 05 Feb 2002 15:31:09 GMT
<snip/>

>> 
>> 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?
>

Sorry, my question is more basic.  Should serializers and generators use the
same element classes...?

>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)
>

I think it is a good thing once I get it clear in my mind:

....cocoon.serialization.HSSFSerializer ---->  {some component}
....cocoon.generation.HSSFGenerator-------------^

>> 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.
> 

more on this privately

>> 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.
>

definitely

>
>-- 
>Stefano Mazzocchi      One must still have chaos in oneself to be
>                          able to give birth to a dancing star.
><stefano@apache.org>                             Friedrich Nietzsche
>--------------------------------------------------------------------
>
>---------------------------------------------------------------------
>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