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.
> 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.
ciao robertj
------------------------------------------------------------
Robert Kuzelj
Gaissacherstrasse 7 email: [EMAIL PROTECTED]
81371 Muenchen tel: 0177/5302230
the trinity of desirables of (software) architecture:
Firmitas, Utilitas, Venustas (marcus vitruvius 20 BC)
strength, utility, beauty
---------------------------------------------------------------------
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]>
