You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by "Schmid, Robert D." <rs...@swri.org> on 2009/02/11 18:05:41 UTC
Sorting
I am facing a situation where I need to sort an excel file. After much
searching I determined that the functionality is not there.
So I opened the source and began to poke around. After reading the
source I have come to the conclusion that it has been deliberately
written to make sorting impossible.
In the HSSFSheet, rows are stored as a TreeMap - an inherently sortable
map but the rows use themselves as keys. The HSSFRow implements
comparable but uses its own row numbers as the comparison value.
I could easily extend these classes for sorting IF
The rows TreeMap was accessible outside the class. It is not.
I could extend HSSFRow and override the compareTo method but HSSFRow is
'final'.
So, why is it implemented this way? Are there some advantages to this
implementation that make it worth blocking out the inherent sort
features of a TreeMap?
Robert Schmid
Senior Research Scientist
Southwest Research Institute
(210) 522-2909
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
RE: Sorting
Posted by "Schmid, Robert D." <rs...@swri.org>.
Hi Dave,
I don't have time right now to do this but here is the approach I would
follow;
1) Make the rows TreeMap available through a getter.
This would allow the user to set a Comparator class for the sheet. It
should have the effect of creating an automatic sorting function. Leave
HSSFRow alone since it defines its 'natural' sort order just fine.
As an alternative to making the TreeMap directly available you could add
method
public void setAutoSort(Comparator sortMethod)
{
rows.setComparator(sortMethod);
}
We could go step further by adding a second ArrayList<HSSFRow> to
HSSFSheet called headerRows. Which would allow us to do 'sort with
header' sorts. Of course, you'd have to fix rowIterator() to make sure
you get all rows if you do that.
I chose an ArrayList instead of a TreeMap for headers because I don't
foresee a need to be sorting and mapping header rows.
-----Original Message-----
From: Dave Fisher [mailto:dave@jmlafferty.com]
Sent: Wednesday, February 11, 2009 11:42 AM
To: POI Developers List
Subject: Re: Sorting
Hi Robert,
I think you have a good idea.
I'm not sure why it was done the way it was done. Perhaps the rows are
not really sortable that way - there may be internal settings.
The reason is more likely that the original use of POI was either to
read to extract information or to write out a report. Now I think that
there are people who want to update a spreadsheet with POI and then
return it to the user.
I'm curious which sort would you apply to the TreeMap? It may make
sense to extend HSSFSheet / XSSFSheet with a sort api.
If you want to try it yourself, you are certainly free to download the
poi source and make TreeMap accessible. I'm willing to take a look at
your result and we can see if it makes a good contribution to the
project.
Regards,
Dave
On Feb 11, 2009, at 11:05 AM, Schmid, Robert D. wrote:
> I am facing a situation where I need to sort an excel file. After
> much
> searching I determined that the functionality is not there.
>
> So I opened the source and began to poke around. After reading the
> source I have come to the conclusion that it has been deliberately
> written to make sorting impossible.
>
> In the HSSFSheet, rows are stored as a TreeMap - an inherently
> sortable
> map but the rows use themselves as keys. The HSSFRow implements
> comparable but uses its own row numbers as the comparison value.
>
> I could easily extend these classes for sorting IF
>
> The rows TreeMap was accessible outside the class. It is not.
> I could extend HSSFRow and override the compareTo method but HSSFRow
> is
> 'final'.
>
> So, why is it implemented this way? Are there some advantages to this
> implementation that make it worth blocking out the inherent sort
> features of a TreeMap?
>
> Robert Schmid
> Senior Research Scientist
> Southwest Research Institute
> (210) 522-2909
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Sorting
Posted by Dave Fisher <da...@jmlafferty.com>.
Hi Robert,
I think you have a good idea.
I'm not sure why it was done the way it was done. Perhaps the rows are
not really sortable that way - there may be internal settings.
The reason is more likely that the original use of POI was either to
read to extract information or to write out a report. Now I think that
there are people who want to update a spreadsheet with POI and then
return it to the user.
I'm curious which sort would you apply to the TreeMap? It may make
sense to extend HSSFSheet / XSSFSheet with a sort api.
If you want to try it yourself, you are certainly free to download the
poi source and make TreeMap accessible. I'm willing to take a look at
your result and we can see if it makes a good contribution to the
project.
Regards,
Dave
On Feb 11, 2009, at 11:05 AM, Schmid, Robert D. wrote:
> I am facing a situation where I need to sort an excel file. After
> much
> searching I determined that the functionality is not there.
>
> So I opened the source and began to poke around. After reading the
> source I have come to the conclusion that it has been deliberately
> written to make sorting impossible.
>
> In the HSSFSheet, rows are stored as a TreeMap - an inherently
> sortable
> map but the rows use themselves as keys. The HSSFRow implements
> comparable but uses its own row numbers as the comparison value.
>
> I could easily extend these classes for sorting IF
>
> The rows TreeMap was accessible outside the class. It is not.
> I could extend HSSFRow and override the compareTo method but HSSFRow
> is
> 'final'.
>
> So, why is it implemented this way? Are there some advantages to this
> implementation that make it worth blocking out the inherent sort
> features of a TreeMap?
>
> Robert Schmid
> Senior Research Scientist
> Southwest Research Institute
> (210) 522-2909
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org