Contains methods used in the predicate factory related to the lookup framework.
***************************************************************************************************************
FIXME: issues to talk to the group about.
http://kuali.org/rice/documentation/1.0.3/UG_Global/Documents/lookupwildcards.htm
1) Should we support isNotNull, isNull, as wildcards? Then do we still translate
null values into isNull predicates. I believe the lookup framework right now
barfs on null values but that is a guess.
2) We need to support case insensitivity in the old lookup framework. Right now the lookup
framework looks at Data dictionary entries. This can still be configured in the DD
but should be placed in the lookup criteria. We could have a "flag" section on a
lookup sequence like foo.bar=(?i)ba*|bing
This would translate to
or(like("foo.bar", "ba*"), equalsIgnoreCase("foo.bar", "bing"))
Btw. My flag format was stolen from regex but we could use anything really.
http://download.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#CASE_INSENSITIVE
I'm currently supporting this.
3) In the above example, I used a case insensitive flag but Like doesn't support case
insensitive. Should it?
4) Do we need to support escaping in the lookup framework & criteria api. Right now the
lookup framework looks at Data dictionary entries. This can still be configured in the DD
but should be placed in the lookup criteria. Escaping is tricky and I worry if we support
it in the criteria api then it will make the criteria service much harder to make custom
implementations. To me it seems it's better to make escaping behavior undefined.
If we do support an escape character then we should probably also support a flag to treat
escape chars as literal like (?l) (that doesn't exist in java regex)
http://download.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#LITERAL
5) Maybe we should just support what is in the org.kuali.rice.core.framework.logic.SearchOperator class
6) Maybe the predicate class could have a toLookupString, toLookupMap() methods on them to translate
to various formats of criteria? Or maybe this factory method & related methods should get placed into
krad or somewhere else?
***************************************************************************************************************
fromCriteriaMap(Class<?> clazz,
Map<String,?> criteria)
This take a criteria map that is commonly used in krad-based
applications and transforms it to a predicate.
This take a criteria map that is commonly used in krad-based
applications and transforms it to a predicate.
The incoming map takes the form of the following possibilities:
propertyPath=value
propertyPath=criteriaSequence
The values in the map can either be a String or a Collection
Note: that the Collection can contain other collections or strings
but eventually must resolve to a string value or string criteria sequence.
a simple example of a propertyPath=value:
foo.bar=baz
would yield
equals("foo.bar", "baz")
a simple example of a propertyPath=criteriaSequence
Related to null values: Null values will be translated to isNull predicates.
The criteria string may also contain flags similar to regex flags. The current
supported flags are:
(?i) case insensitive
To use the 'i' and 'm' flags prepend them to the criteria value, for example:
(?im)foo
Only the first flag sequence will be honored. All others will be treated as literals.
Parameters:
the - root class to build the predicate on. Cannot be null.
criteria - the crtieria map. Cannot be null or empty.