On 9/20/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
one thing confuses me: why the boolean params for missing/zero in the method declarations for getFieldCacheCounts and getFieldTermEnumCounts ?
I envision multiple ways of getting facet counts, with the most efficient being called based on heuristics, cached term information, etc... putting param parsing into each of these methods doesn't seem right. Notice how the new method I added is package protected... I'm not yet sure at what level the public API should be.
... for getFieldTermEnumCounts i was pulling that info from the protected member variable "params" to keep the method signatures simple for when the day comes that we want the behavior to be driven by additional params
Depends on what one things the "entry" point should be, or the unit of re-use. If someone is implementing their own custom handler, they may very well be doing param parsing differently. The lowest level routines should perhaps even be static and have everything passed into them (searcher, field, options). I'm flexible though :-)
(i expect there will be custom subclasses to SimpleFacets in the future reusing these methods, and i'd hate to keep adding method params that make it hard for those subclasses)
I haven't thought much about it, and I don't know what you had in mind... but would someone really override methods of SimpleFacets? It seems more likely that they would use it more as a library resource, calling methods to do different things as needed, and that can easily be done with composition rather than inheritance. -Yonik
