- robert
On Saturday, October 4, 2003, at 05:02 PM, Henri Yandell wrote:
I'm -1 to Lang. Comparators are not within its scope.
It does sound like the generic comparator is really just a factory method for creating a structure of Collections comparators with a Bean comparator structure. I believe it should be a static method on the BeanUtils BeanComparator class. BeanUtils has a dependency on Collections if I'm not mistaken, so can happily get the Collections reuse, without coding the bean handling stuff again.
Hen
On Fri, 3 Oct 2003, Dirk Verbeeck wrote:
The easiest way to contribute to to integrate/add your code to an existing project. Commons-lang looks likes a good place to start: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/ package-summary.html http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/ CompareToBuilder.html
But there is also: http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/ ComparatorUtils.html http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/ comparators/package-summary.html
Your "|" operator is a ComparatorChain <http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/ comparators/ComparatorChain.html>
order=desc is a ReverseComparator <http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/
comparators/ReverseComparator.html>
and nulls=last can be done using NullComparator <http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/ comparators/NullComparator.html> and your getCustomer.getLastName lookup is something for beanutils, jexl or jxpath
Your simple expression would be indeed a time saver for constructing a custom comparator. Did you already use some of the existing commons code? If you did then I think either commons-lang or commons-collections will be interested.
Dirk
Wickus Martin wrote:
A while back I wrote a generic comparator for Java objects and called it
GComp. Weve been using it internally at the company where I work, but I was
wondering if it might not be of value to the commons project.
Typically Java programmers create a custom Comparator implementation for
every comparison scenario they encounter. GComp on the other hand can
compare objects according to complex criteria based on a simple expression
that explains how the objects should be compared. Great time saver and
prevents problem of many small comparator classes bloating the code base.
Usage scenario:
Lets say we have a class called Customer with methods to access the first
name and last name. Lets also say we have a class called Order that holds a
reference to an instance of Customer.
To compare orders according to the customer surname (ascending) we could create the following comparator:
new GComp("getLastName");
To compare a collection of orders according to the customer last name
(ascending) and then first name (descending) for those customers with the
same last name we could create the following comparator:
new GComp("[EMAIL PROTECTED]|[EMAIL PROTECTED] desc ");
To order null values last and ignore case we could create:
new GComp("[EMAIL PROTECTED],nulls=last|getCustomer. [EMAIL PROTECTED],nulls=last");
The above code only orders on string objects, but all objects implementing
the comparable interface is supported as is primitive types.
Currently GComp uses commons-logging to output debugging information if commons logging is found on the classpath.
I'm happy to donate the code for further study. Let me know.
Keep well, Wickus Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
