Return-Path: X-Original-To: apmail-poi-dev-archive@www.apache.org Delivered-To: apmail-poi-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1DAA718F97 for ; Tue, 3 Nov 2015 21:53:34 +0000 (UTC) Received: (qmail 97276 invoked by uid 500); 3 Nov 2015 21:53:34 -0000 Delivered-To: apmail-poi-dev-archive@poi.apache.org Received: (qmail 97233 invoked by uid 500); 3 Nov 2015 21:53:34 -0000 Mailing-List: contact dev-help@poi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "POI Developers List" Delivered-To: mailing list dev@poi.apache.org Received: (qmail 97221 invoked by uid 99); 3 Nov 2015 21:53:33 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Nov 2015 21:53:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 4343218028C for ; Tue, 3 Nov 2015 21:53:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.879 X-Spam-Level: ** X-Spam-Status: No, score=2.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id OOhtb7aotFl2 for ; Tue, 3 Nov 2015 21:53:31 +0000 (UTC) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id EC9A820FF5 for ; Tue, 3 Nov 2015 21:53:30 +0000 (UTC) Received: by wicfx6 with SMTP id fx6so78169294wic.1 for ; Tue, 03 Nov 2015 13:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RWozy43v1Jvc0inb/Pcv6H7SY98dazwBN9eyIHZSwJY=; b=H0FgAAk2gRsJTRmCaUWhfM+vGrMR57yrjN/sAWX10KB7mqqSVBK8IcOGBV43uFUb6P zKu+B0Fi5Z3l6g5Dn63zDLLt7/2NuVnG0pJI1F5iaiQHBNY/4EWfSPJb9i+ZIiKmmxf+ 9NNoaiVjf43c/ML7Aqiyww9AVld8z4TNSKgDER5mNlLQmaGi/tYnEZr6OAwsF5COZx0r O3TAGtzq64186X40N2D+w4p8QJSs+Lv1tCqcUaCMwgz6AZrjhv+cIunz6CC7n53Vq+Vt YQSKpN8SV+8tiSHjgTnmyGgtsr1XTutkuCqi/48qhH8BVLtefmMNzxrZBNqyL33kOnLD u+ow== MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr16903446wjc.108.1446587603790; Tue, 03 Nov 2015 13:53:23 -0800 (PST) Received: by 10.27.13.23 with HTTP; Tue, 3 Nov 2015 13:53:23 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Nov 2015 22:53:23 +0100 Message-ID: Subject: Re: Bug 57450: Patch submitted, request for feedback From: ST To: POI Developers List Content-Type: multipart/alternative; boundary=089e010d851042b3370523a9ec3c --089e010d851042b3370523a9ec3c Content-Type: text/plain; charset=UTF-8 Javen, Thanks for the feedback, I will look into it. Regarding SXSSF#autoSizeColumn(): the current implementation works fine and calculates autosize based on the content of the current window. So no problem with keeping the current implementation. But isn't that confusing for users? I'd prefer to throw an exception to "force" users to use either the fully supported autosize method, or none at all. On Tue, Nov 3, 2015 at 6:48 AM, Javen O'Neal wrote: > Stefan, > > First off, thanks for the hard work and thought you put into improving the > streaming workbook interface. It's certainly a challenge to work with > columns on such a row-centric interface. > > Here's some critical feedback on attachment 33207 from comment 7 of bug > 57450, mostly pertaining to the AutosizeColumnTracker class. > > In AutosizeColumnTracker: > > You should iterate in determinstic ascending order when iterating over > monitoredColumns to calculate maxColumnWidths. The easiest way to do this > is to change monitoredColumns from TreeSet to HashSet. > > You are maintaining two data structures, monitoredColumns and > maxColumnWidths, however monitoredColumns just equals the keys of > maxColumnWidths, so you can eliminate monitoredColumns altogether, using a > TreeMap for maxColumnWidths. > > You have a method to add one column at a time to the columns-to-monitor > set. It might be helpful to provide the following methods: > monitorColumn(int columnIndex) > monitorColumns(Collection columnIndices) > unmonitorColumn(int columnIndex) > unmonitorColumn(Collection columnIndices) > The latter two may be needed if a user needs to scan rows in a sheet to > determine if a column needs to be autosized. If the user doesn't monitor > the columns from the very first row, the autosizing result may be incorrect > if cells in the first row need to be wider than any remaining rows. For > execution speed, it's best to prune unnecessary column width calculations > as soon as the user knows they're no longer interested in it. > > applyAutosizeToColumn seems clunky--the user needs to remember which > columns they want to autosize, and auto-size them one-by-one. Can you > replace this with or add an autosizeMonitoredColumns method so users don't > need to maintain duplicate data structures of monitored columns? > > I think your code works correctly for this, but did you test for both > cases: current column width is too wide and current column width is too > narrow? > > You can't deprecate SXXSFSheet#autoSizeColumn(int) or #autoSizeColumn(int, > boolean) because these are both required by the Sheet interface[1]. You can > replace these with a javadoc that says "not implemented for SXSSFSheets, > use {@link AutosizeColumnTracker} instead" and throw an > UnsupportedOperationException or RuntimeException, but it'd be even better > if you could figure out how to keep these methods (Do they currently only > work if the entire sheet fits within the window? Do they currently only > autosize based on the content that is in the current window? Do they > currently not work at all?) > > AutosizeColumnTracker should have unit tests (ideally 100% coverage) and > example code in the users guide. Writing both has the added benefit that it > gives you another chance to see how this class would be used by client code > and identify the weak points of its interface. > > I will commit the minor stuff (mostly typos) that were identified in this > patch. > > [1] > > https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Sheet.html#autoSizeColumn%28int%29 > > > On Mon, Nov 2, 2015 at 12:00 PM, Stefan Thurnherr < > st.mailinglists@gmail.com > > wrote: > > > I've submitted a patch and added some discussion points to this > enhancement > > request over a week ago: > > > > "A way to autosize columns on SXSSF" > > https://bz.apache.org/bugzilla/show_bug.cgi?id=57450#c7 > > > > Could someone please have a look and give feedback? Thanks! > > stefan. > > > --089e010d851042b3370523a9ec3c--