On Tue, Dec 16, 2008 at 2:10 PM, Chris Hostetter
<hossman_luc...@fucit.org> wrote:
> Assuming i'm understand you (and your original example was just
> transcriptiong mistake)
Correct, it was a mistake.
> then i go back to the basic point of my original
> question about "huffman encoding the common case ...
> should we make "facet.field={!exclude}X" be shorthand for
> "facet.field={!exclude=X}X" ?
We need the latter for more complex scenarios (what is displayed as
one facet may not be), or for even faceting on the same field
different ways.
As for shorthand, {!exclude} is already shorthand for {!type=exclude}
in localParams syntax.
> Alternately: is seems likely that people who want this type of
> multi-select behavior will want it for all/most of their facets ...
But the relationship between a single "GUI" facet may not be
one-to-one with behind-the-scenes Solr facets.
> so
> perhaps instead of the {!exclude=X} local param, we should add a new
> facet.multi=(true|false) param that can be specified on a per-field basis
> ... so f.type.facet.multi=true means facet.field=type ignores any fq's
> where "tag=type".
That also wouldn't work for facet.query
> This would probably even be possible as syntactic sugar
> in addition to the {!exclude=X} syntax, so in the common case people would
> just use facet.multi=true and forget about it,
It's not that simple though, since they have to correctly tag all the filters.
And setting multi=true isn't really descriptive (as you've noted in
the terminology discussions). Excluding certain filters when faceting
is very descriptive, and avoids any mention of what the GUI layer is
trying to accomplish.
-Yonik
> but in weird esoteric
> situations where they want filters on field X or field Y to be ignored by
> faceting on field Z they could still use "facet.field={!exclude=X,Y}Z"
>
>
> -Hoss
