arschr wrote:
It uses reflection to grab a propertydescriptor of the property it represents, then reads the value of that property and uses that value in the predicate interpretation.
If you would pass an EntityField2 object, the predicate would use the field's value in the predicate interpretation.
My point is that
new EntityProperty(entityFieldName)
doesn't provide any information about the field name thats been generated.
if the mapped field was returned from the EntityFieldFactory call
new EntityFieldFactory("EntityName","EntityFieldName")
, I could determine more about the field such as it's datatype which can control the type of predicate expression I need to build to filter on a field.
i.e. like doesn't make sense on int's, = false only makes sense on bools, etc.
Ok, though it was my understanding that the value to compare with was specified in a textbox?
Anyway, the interpretation of a predicate is done as follows:
The entity is passed to the predicate expression to interpret. It should return true or false. If you create a FieldCompareValuePredicate using new EntityProperty or using a field, it doesn't matter, the object used (field or entityproperty) gets the entity and returns the value represented by that object (field or entityproperty). That value is then compared with the value specified, using a string compare, as dataview does too, in the case of Equal. All other operators use a general comparer object which compares the values based on the operator specified.
Thus, IMHO, you can just specify the value you want to compare with and the property you want to compare and that's it.
With the call
new EntityProperty(entityFieldName)
, I don't see any binding to the entity itself, so that if I have properties on 2 different types of entities that have the same name this call returns the same object for each, doesn't it.
That's ok, as the entityproperty gets the entity passed in and returns the value for the property it represents (if present, otherwise null). In-memory filtering is about: you have a filter and you apply it to an entity. So the interpretation logic works with a given entity and it doesn't need binding to an entity, it will resolve the values at runtime.
Obviously, using a Customer.CompanyName field on an orderentity won't result in a value.