> > 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 :)
kHen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
