On Jan 8, 2007, at 3:13 AM, Chris Hostetter wrote:
: > with a single schema -- but dynamicFields are used to store
category
: > specific fields, so that if you are doing a category specific
search,
: > category specific filters can be offered to you...
: >
: > http://shopper.cnet.com/4144-6501_9-0-1.html?query=canon
:
: Could you elaborate a bit more about how the front-end and back-end
: work to communicate the category specific filters?
:
: Showing *all* facets from the start can be unnecessarily too much
for
: a user to navigate, so I'm interested in how to develop a system
that
: can adjust the facets shown based on context a bit more elegantly.
I'm not sure i understand the question. Our Facet lists (and
per facet constraint lists) are specific to each category -- once a
specific category has been specified by the application server, a
custom
request handler parses the list of facets/constraints from a metadata
document for thta category, computes the intersection for each
constraint
query and returns *all* of the information to the application -- it
normally shows only the first 3 facets not yet constrained, and for
each
of those facets it shows the labels for the "best" constraints,
where the
defintion of "best" depends on the data type of the facet -- by
default
it's the ones with the largest counts, or in "natural order" for
numeric ranges, but there are overrides for extremely popular
constraints.
there are a lot of optimizations that could be done in the Solr
plugin to
only compute the counts for facets/constraints we know we wnat to
display
-- but i specificly made it compute everything so the frontened
could make
whatever choices it wanted about displaying facets without needing to
change the Solr plugin. (it's on the list as a potential
optimization to
move some of that logic into the requset handler, but there haven't
been
any complaints about hte performance)
does that answer your question?
sorry for the delayed reply. that answers the question perfectly,
thanks!
Erik
