Filter and Expression evaluation not always use the new evaluation framework
----------------------------------------------------------------------------
Key: GEOT-1255
URL: http://jira.codehaus.org/browse/GEOT-1255
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.4.M1
Reporter: Gabriel Roldán
Assignee: Gabriel Roldán
Fix For: 2.4.M2
f you remember, I've talked about using a custom FilterFactory and thus
Filter* implementation for dealing with ISO Feature.
It turned out to not be necessary, as the Filter implementation is "pluggable"
enough (i.e. using PropertyAccessors and Converters should just make the
trick).
The problem I've faced early was Filter evaluation (such as Equals, etc) did
not know how to extract the value of an org.opengis.feature.Attribute to
compare against, for example, a Literal.
Once again the latest filter design seems to be thought well enough as to
handle this. the problem is two fold, Filter and Expression evaluation.
Filter evaluation is mostly handled by delegating to
FilterAbstract.eval(Expression, Object), for which the only needed change is
to check if object is an Attribute, and in that case to return the Attribute
content:
{code}
protected Object eval(org.opengis.filter.expression.Expression expression,
Object object) {
if( expression == null ) return null;
Object value = expression.evaluate( object );
if(value instanceof org.opengis.feature.Attribute){
value = ((org.opengis.feature.Attribute)value).get();
}
return value;
}
{code}
This handles, for example the equality check (IsEqualToImpl) with no change:
{code}
final Object value1 = eval(expression1, feature);
final Object value2 = eval(expression2, feature);
{code}
Also note this does not adds a dependency over any unsupported module, since
the dependency over geoapi is already there, and we're only checking for a
geapi interface.
....
By the other hand, Expression's evaluate methods make use of Converters to get
a value adjusted to its expected type.
In this case no code change is (should be) needed, but adding an
AttributeConverterFactory handles it.
I say "should be" because, even if the framework is well thought, not all
classes are adapted to work with it.
Take for example LenghtFunction, it does:
{code}
public Object evaluate(Object feature) {
Expression ae = (Expression)getParameters().get(0);
return new Integer(ae.evaluate(feature).toString().length());
}
{code}
where the following options handles it far better:
{code}
public Object evaluate(Object feature) {
Expression ae = (Expression)getParameters().get(0);
String value = (String) ae.evaluate(feature, String.class);
return new Integer(value == null? 0 : value.length());
}
{code}
This way, we explicitly tell the attribute expression to evaluate to a String,
so no need to guess or customly handle a different object type.
With this few changes, we would be a big step forward in actually making
Filter to easily work with whatever object model we want.
Note the build keeps completely sane after doing this change, so it would be
nice to directly incorporate them to the code base instead of having to fork
something.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
