[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
- 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. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
