cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Excel generator
Date Wed, 24 Jul 2002 10:07:39 GMT wrote:
> hi oliver,
>>Well we do have some samples, but its been limited at the moment by kind
>>of a chicken and the egg scenario.  The serializer is there, the samples
>>are there but we can't more because we don't have any usage scenarios
>>except for mine (translation: lots of people are using POI but few
>>people are using the serializer).  But that may in itself be the reaons
>>that we don't.
> i guess the problem is another one (imho). at the moment the whole
> serializing stuff is to much tied to cocoon. this makes it virtually
> infeasable to use it simply out of the box with poi. i would have
> not made it run without the help of sven (so here once again thanks
> to sven). all those jars of one does not know which ones are necessary
> and which are not - not to mention the fact that when deploying all
> of them you surely increase the proballity of jar-hell (one of the
> biggest problems in large java-development-shops).
> another problem at the moment is, that concrete interface for the
> HSSFSerializer is way to complex. you have to create all this
> logging-stuff and readers and so on. well i'd say "no batteries included".
> something like:
> OutputStream os = (new HSSFSerializer()).convert(gnumeric_file_or_stream);
> would be much easier to use for newbies.

This is in the works, as project Morphos in Commons scratchpad.
Someone has already a working standalone version of the serializer, and 
we will put it in Morphos.

Morpher myMorpher = MorpherFactory.getMorpher("hssf");
mymorpher.morph(gnumeric_file_or_stream, os);

>>Are you using the serializer?  For what?  how?
>>...and then bug reports and requests could drive the development a bit
> more.
> we (that is my customer) are using it to create invoive-files which in
> a later stage will be converted to pdfs.
> we are still in early development so i cant say how well it will work out.
> but we will generate more than 300 invoices per week and the number is
> going to increase.
>>Well it actually kinda sucks and is probably hard to hand generate.  It
>>probably actually sucks more than
>>the Gnumeric format, but it more cleanly maps to the file format.
> hmm, i think the gnumeric-format is not so great, even thou i have to admit
> that there even worser ones.
> what is on the one hand realy nice is that the formating part is separeted
> from the content part but that is also the drawback. when changing the file
> by hand you almost surely f*ck the whole thing up. actually that is what
> i did on thursday of last week: destroying 1 1/2 days of work when trying
> to make a stylesheet out of a gnumeric-file.
> i settled now for a multistage-process. i'll fill in variables in the
> format of ant ( ${varname} ) in gnumeric -> replacing the variables
> by means of regex with '<xsl:value-of select="var-substitute">' and then
> merging the stylesheet and the date to a gnumeric-file and this one is
> being serialized.
> but what i want to do later to is to create a pdf-file instead of an excel-
> file. i'll be using xsl-fo for that and i see some hard times coming to
> first create an xsl-fo file out of gnumeric.
> but to be honest i dont know any better solution than gnumeric. and at least
> the solution is symetrical gnumeric->excel->gnumeric.

Yup. And XSLT files for easy conversion to the Excel format.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message