Michael Zalewski wrote: >>Early on, to my suprise, most folks were using it for reading, but >>I think that was mostly a perception/marketing problem. >> >>
Thanks for your reply. See my responses in-line. This may sound defensive, its not. I just want to clarify the use cases a bit. >It doesn't surprise me at all. > >The reason why so many people use it for reading is because there are some >very simple ways of dealing with writing. But there is no other free >solution that understands how to read native XLS. (Actually... there may be >some tools not written in JAVA. Would be interesting to compare these to >POI). > > yes I've used them. >If you want to write, you can output a .CSV formatted file (comma seperated >values). If you want to add some amount of formatting, you can output a HTML >document that contains a table. This can be read by most versions of Excel >as a single sheet. Some of the HTML table formatting is translated into the >proper Excel formatting. I know neither of these alternatives are as >powerful as POI. But these techniques are quicker and easier, and may >provide enough features to get the job done. > > HTML table chokes Excel for any bigger than trivial sized sheets. Generall solutions I put out support three: XLS (native...would now be with POI, in the past I used Formula 1) HTML CSV (fastest, smallest) >I have also seen (somewhere I forget where) a solution that writes an older >Excel format (the original BIFF format, not contained in an OLE structured >document). I believe that solution was written in PERL, but it was quite >complete. This allowed all of the formatting, but was also only a single >sheet. > > Yes, we used this early on to figure out the OLE 2 CDF. >Another choice, if your users have Excel 2000, is to output in XML. I >haven't tried it, but apparently the XML format can accomodate everything. >Microsoft used to call this 'round-trip' XML support, meaning that an Excel >document could be saved in XML format, then read in again without loosing >any of the formatting information or data structure. > > Again, chokes on large documents. And is even less efficient than XLS for transmission purposes. >These alternatives should probably be considered before choosing POI to >write native Excel. In a webserver environment, these alternatives have the >following advantages over POI. > >1) They are (with the exception of original BIFF) the vendor's supported >method for another application to export data to Excel. So we don't have to >worry about the next version changing things around. > > The format has not changes substantially since 1995, and only very trivial additions since 1997. We picked Excel 97 because its the most widely used and versions for some time to come will need to support it. Excel 2000 - XP are just 97 format with a few extra (useless) records that serve no purpose that I've determined other than make sheets non-backward compatible. >2) They are simple. You don't even need an API to write a CSV file. Most web >server application already write lots of HTML tables, and many already deal >with XML. > > Again, I generally give users a choice fast, good, or cheap -- pick 2. Large sheets and those with fomulas and formatting are best in XLS format. Secondly, >3) They are easy to understand. Most web developers already understand how >to use CSV file, or write HTML or XML. > > Is the POI API harder to use than SAX/DOM? Hummm? >4) They stream. You don't have to generate the entire contents of the file >first. OLE Structured documents contain a header whose bytes cannot be known >until the entire file has been generated. > > This is the biggest disadvantage to POI. >5) They are compact. They take significantly less bytes than a full OLE >structured document. And when used in an application such as a web server, >they do not require all the bytes to be held either on disk or in memory. >POI in its current implementation seems to require us to generate the entire >document in memory. > > Not the XML/HTML. Yes with CSV. Larger sheets start getting huge in XML/HTML (and they crash Excel) >On the other hand, there might be some reasons why you need POI. But none of >the following reasons seems to be the kind of thing that will make or break >a system. > > That depends on the customer. >1) Advanced XLS features, such as charts, cannot be accomodated very easily >with any of the 'dumber' alternatives, except possibly Excel 2000 XML. > Again certainly if your customers are on Excel 2000+ and the sheets are small and will always be small thats fine. > > >2) Excel 2000 XML requires Excel 2000. Excel 97 does not support XML AFAIK. > > true. >3) The ability to read XLS format opens up new possibilities, such as using >a template XLS file which contains headers, and updating the template with >results from a database query. > > true. >4) Bill Gates probably does not want this kind of tool to exist. Open Source >is cool. > > ;-) Nor does Acutate who sells something similar for $15k per processor. >5) The primary advantage of POI is that it can read the same file that the >user saves to their disk when they use Excel. The users don't have to worry >about 'Save As' or have heart palpatations when Excel warns them that they >may loose some of their work if they continue. > > I'd say that is an advantage, I'd not go so far as to say "primary". 6) You have reports being generated in XML (Cocoon) or via Java that would traditionally need to be done by hand (waste of time). These reports have formulas, borders, and all the frills. Your user base is varied with Office 97-XP bases. Your sheets are of varied sizes and complexity and you don't like Excel to crash. -Andy > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
