: 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
but the bueaty of hte SolrParam class is that it isn't inheriently tied to request params .. a custom request handler that wants it's own way of determing the faceting behavior could construct an arbitrary MapSolrParams for use in the constructor to SimpleFacets. : should perhaps even be static and have everything passed into them : (searcher, field, options). I'm flexible though :-) i avoided statics because it makes it hard to future code to customize *some* of the behavior ... ie: right now a client could subclass SimpleFacets and override just the getFacetFieldCounts to include an optimization like the one you provided, and still leverage both the "lower level methods like getFacetTermEnumCounts and getFacetFieldMissingCount from within their new version, as well as trusting that the "higher" level getFacetCounts will call their version of getFacetFieldCounts. If any of those methods had been static, custom client code would need to cut/past a lot of the "glue" again. : 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. If everything is static, then they *have* to use it as a library resource and all of hte glue methods (like getFacetCounts) have to be rewritten, and custom clients don't get to take advantage of future additions as easily. They can still choose to compose a SimpleFacets instance and treat it as a collection of utilities, but i'd like to make sure subclasses that only override a small piece of the functionality are easy to write. (we kind of have hte same problem with the request handlers right now: with all of hte funcionality directly in handleRequest, it's hard for people to subclass it and override a small bit of functionality without cuting/pasting a lot of code ... which is one of the reasons i added the StandardRequestHandler.getFacetInfo method, even though all the real work is in SimpleFacets -- if developers want all of hte behavior of StandardRequestHanlder, but have their own more complex Faceting system they want to use, they can write a 3 line subclass and still benefit from any future additions to StandardRequestHandler. -Hoss
