Extended Facet

[Jonathan Ariel <io...@gmail.com>]

Hi!I'm working on a extended facet which will give some more information
like: Max value and Min value, for numeric field types it will also bring
SD, MEAN and CV.

Any thoughts or recommendations?

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:
FieldType
  StringFieldType
  DateFieldType
  NumericFieldType
     DoubleFieldType
     IntegerFieldType
     ...

Just an idea.

Jonathan

Re: Extended Facet

[Jonathan Ariel <io...@gmail.com>]

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 <ho...@fucit.org>
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
>
>

Re: Extended Facet

[Chris Hostetter <ho...@fucit.org>]

: 
: 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