commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [COLLECTIONS] Comparator observations
Date Thu, 28 Feb 2002 21:36:22 GMT

> > Agreed. Should UrlComparator live with Url?
> > The other two I guess are more
> > Util stuff? Hard to package them. I solved it by having all my comparators
> > in a compare pacakge.
> How about I just re-add UrlComparator and NumericStringComparator to Util
> for now, and we can go from there?

They're both mainly presentation based. I disagree that they're
application specific, but they are common presentation level components
rather than generic anywhere components.

UrlComparator doesn't try to fix any UrlStreamHandler issues, but orders
the Urls in a more usable way.

> > NumericStringComparator however is something I've often seen people asking
> > for. It's not a simple implementation (well for the level of people asking
> > for), so I think it has a lot of uses. It's all opinion though, so I
> > dunno.
> To me, this one does stand out from the other two as potentially
> appropriate.  What would a class like this be used for?  It still _sounds_ a
> little application-specific, but maybe not.

It's presentation specific, though I guess it could be used without. My
most recent usage was in a JTable. The JTable columns were normally
numbers, but could be strings, so I used String as the type of the cell.
Sorting on String is bad as it places 51 before 6. So
NumericStringComparator came in handy. I originally wrote it due to people
asking how to do such a thing on a forum and the suggested answers all
looking horribly heavy.

However, server-side components can still be presentation specific I
figure. A previous usage was in a jsp page. Maybe the
Commons...comparators need to be bound to a sorting taglib if we've not
got one already :)


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message