> > >>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. >
Yeah in short: Its a Cocoon Serializer. While I appreciate this feedback, I personally have no use cases for the Serializer outside of Cocoon. This makes it impossible for me to support a non-cocoon version of the Serializer. It would take a motivated individual who knew what to do in order to support such a project. My continued personal interest is in generating reports via Cocoon and the HSSF Serializer. >>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. > > Cool! Would you mind writing up a case study for POI? http://jakarta.apache.org/poi/casestudies.html I'll look through what Sven did. My only concern is whether you'll end up with Cocoon anyhow as your project scales up. >>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. > > Well one thing I don't recommend is generating the gnumeric format directly once you know what you're doing. Meaning come up with an interim format. XML-> YOUR XML -> Gnumeric XSLT XSLT The first XSLT converts your datafeed into an XML Invoice (your own tag langauge). The second stylesheet generically applys styling to this and makes it into a Gnumeric workbook. >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. > > I don't think it has to be if you do as above. >but to be honest i dont know any better solution than gnumeric. and at least >the solution is symetrical gnumeric->excel->gnumeric. > > You prefer this to the Excel xml format? -Andy >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]> > > > > --------------------------------------------------------------------- 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]>
