I like the idea of returning a bogus response, so I don't need to handle special cases, like strings. And by doing that the extra levels of FieldType are not needed. Yes, I think I'll change the patch to support that.
Thanks! On Sun, Jun 1, 2008 at 4:32 PM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > : > : Looking into the code I found out that all the field types implement > : FieldType, that's fine, but maybe we can refactor that so we have more > : levels like: > > ...the goal being that then your extended facet code could add the extra > stats when it sees that the field type extends NumericFieldType? > > That seems fine to me ... but a more robust solution might be to just > introspec > toObject() method on the fieldtype, and test if that extends Number (then > your code will work even if people write their own field types that don't > extend NumericFieldType) > > That assumes you are using toObject to get the values to do computation on > ... if you're using ValueSources then you don't have to worry about it at > all -- every field supports it, even the non numeric ones (using > OrdFieldSource) .. if the user asks you to give him the standard deviation > of a string field i think it's fine to give back a bogus answer (or you > could put a special case in and return "not applicable" if the ValueSource > is an OrdFieldSource) > > > > -Hoss > >
