Hello, I request a minor enhancement. (I can't use english well,please read with patience...Can you understand my summary?) Font and CellStyle records are managed in Workbook object,and used Flyweight pattern. If two cell's attribute(cell style and font) are all same,we must set same object at both cell to avoid generating invalid Workbook,because attribute object's number is over a limit. But it is not convenience for users.(and for some commiters? because many report about it is submitted to ML repeatedly... ) Please implement cell's attributes like this(or on some better idea.I don't know the implementation deeply:) ), 1.HSSFCell#setCellStyle(HSSFCellStyle) causes like String#intern(String).If there are already registered a object that has same attributes,instead of registering parameter object,the cell use the object already regeistered as the cell's attribute. 2.HSSFCell#getCellStyle() returns, not raw attribute object's reference,but a shallow copy of it,to make users disable to change the cell's style attribute directly. 3.and other some implementation for it. Thank you for reading.
Hi. Your English is just fine. I have though about this and I think it's a good idea and it should be possible to implement something like this. I don't personally have time to pick this one up at the moment but hopefully another developer might be able to look into it.
No it shouldn't be done. The reason being is you can manage groups of cells's style. Excel behaves in this way. We should however throw an exception if someone creates too many of them.
I made a system to manage this: An ExcelDocument that behaves like HSSFWorkbook but - uses Hashmaps to store created HSSFFont and HSSFCellStyle - don't return any HSSFCellStyle An ExcelFormat that contains the same data as HSSFFont and HSSFCellStyle An ExcelFormatKey that contains a HSSFCellStyle When a developper want to create a style for a cell, he uses ExcelFormat. When he want's to apply it on a cell he has to use the ExcelFormatKey corresponding to it. He gets ExcelFormatKeys through ExcelDocument that checks if HSSFFont and HSSFCellStyle exists, if not a single HSSCellStyle or both HSSFFont and HSSFCellStyle are created. The developper doesn't the see the "POI" objects. It is slower, but it is easer not to store all the existing HSSFFont and HSSFCellStyle. Perhaps this way of solution could help you Question : Is there any forum where we can discuss about poi?
There's a mailing list. Just send an e-mail to poi-dev-help@jakarta.apache.org and see what happens.
I tried to send a mail to this adress but I received : "Hi! This is the ezmlm program. I'm managing the poi-dev@jakarta.apache.org mailing list. I'm working for my owner, who can be reached at poi-dev-owner@jakarta.apache.org. This is a generic help message. The message I received wasn't sent to any of my command addresses."
Yes! Just keep on reading that e-mail and you'll see what you are looking for.
Ok, my fault : I thought of help on POI and not help on using poi's list :-( Sorry,
Hello, Now I'm making a Wrapper Library of POI in my business. In my library I made a management system of font and cell's style attribute. In my library there are workbook,sheet,font,cell's style and etc classes, and user can freely create instance of font and cell's style,and set it to each cell object.Thease classes are not related to POI's classes. And when user call serialize method of it,my library create a HSSFWorkbook, and other POI's objects as the model of my library.And in this turn,my library do like this, 1.Collect each cell's style and font. 2.Check duplication of thease objects and dispose duplicated one. 3.Create HSSFFont and HSSFCellStyle object based on this adjusted collection. 4.Set it to each HSSFCell. I feel,if usermodel package behave like this(User neet not to understand low layer architecture of POI and neet not to manage thease attributes on user's responsibility),we can use POI more easily. Of course,the policy of POI usermodel is already exist and it can't permit this plan,I feel it is a reasonable decision and I will respect it. To tell the fact, I feel troublesome to implement the system in my library, and if POI support this part, it make me more easily :) Thanks.
Good idea. I had the same problems as yours! But I have a few questions for you : Are you able to represent easily with your own model: merged regions, ... ? How long does it take to serialize a file containing 10,000.00 rows and 7 columns on each row ?
can you like, join the mail list? Secondly, I'm pretty sure this already exists in the contrib module. Talk on the mail list, not bugzilla.
Created attachment 5155 [details] Input Excel File for the Testcase. Name "Input.xls"
Created attachment 5156 [details] Testcase for see this problem.
Sorry, I made a confuse about this problem. I submitted a simple testcase to see this problem. In "Input.xls",Cell A1 and A2 in the sheet "Test" has same attribute about cell's style.And In the testcase source is simply do 1.Load "Input.xls" 2.Get HSSFCellStyle about Cell A1. 3.Call HSSFCellStyle#setBorderBottom() ande change style attribute A1's cell. 4.Save as"Output.xls" And checking "Output.xls",Both A1 and A2 Cell's style is changed. It is correct behavior under the structure like now,but user may feel it is bug or not convinience. What do you think about it? Thank you.
Sorry, not "A1 and A2",but "A1 and B1".
-1 On removing the abillity to have duplicate cell styles. -1 on putting anything in the core API which allows people to thoughtlessly iterate throw A LIST of cell styles so that they complain later on how slow HSSF is when they misuse this for thousands of operations. +1 on an acceptable utility class however I'm pretty sure that there is one in the contrib module. If it isn't Pattern-correct, thats certainly not my itch, but patches are welcome. Making HSSF fit into your conceptualization of what the file format is, thats your job (the application developer). We're mapping what it ACTUALLY is, which is that two equal in appearence but actually different styles can and often do get written to the file. Changing one of the visually equal styles changes a group of cell styles. This is used by one of my clients and I'd be HARD pressed to disable this feature just for convienence. Come up with a solution that preserves the behavior and submit a patch. If its unspoken ineffieciency or is complex (such as iterating through a list over and over) then please patch against the contrib module. Note that on the whole I try to keep the API easy to use but I don't like cluttering it with convienience functions at this stage. Once all hard problems (formulas, graphing, embedded graphics, memory, io-mapping) are solved then we'll talk. However I don't want to clutter the core API with a lot of bells and whistles that WE have to maintain until then. (Thats what contrib is for) I'm closing this bug and putting it as invalid. MOVE THIS ONTO THE DISCUSSION LISTS. If you're having trouble posting to the disucssion list (aimed at gr_nico), perhaps you should consider reading directions (hint: subscribe). Toshiaki, I think you'll get along great in the POI community and I look forward to continuing this discussion on the developer list.