Thanks everybody, for your input, I very much appreciate it. My use case goes in the direction of what amazon is doing. Search for a movie, and then, in the "format" facet choose one or more values such as "blue ray", "dvd", "vhs", "betamax" ... so it's not an exclusive selection. this would probably expressed in the query as "format:blue-ray OR format:dvd", for example.
I think I will use the two-query approach, as they are so inexpensive, and then compare both lists. It could be interesting to see whether storing them in a map could be done efficiently. I don't have more than four facets, and not more than twenty values per facet. Evan, I will study the RunDMC code in more detail over the weekend. I'll probably need to get my head around the fact that you're doing things from XSLT whereas I'm writing the application code in Xquery, and the "important" bits of the presentation layer are done in XSLT (search results transformation, display of information for an object). It will be fun. cheers, Jakob. On Thu, May 10, 2012 at 7:29 PM, Evan Lenz <[email protected]> wrote: > That's actually how I implemented search on the Community website: run > search:search twice if a constraint is selected—once to get the results and > once to get the whole facet list as if no constraint had been selected. > > I detailed my use of the collection constraint in a blog article > (http://community.marklogic.com/blog/collection-constraints-are-cool), but I > glossed over how I got the "All categories" "facet value" to appear in the > UI. > > You can see how I'm using two different sets of search options > ("search-options" and "facet-options"): > https://github.com/marklogic/RunDMC/blob/master/view/search.xsl > > But Colleen's suggestion is the most efficient; I think my code is returning > facets both times (when it invokes search:search twice) and it really only > needs to return them one of the times (and just always call search:search > twice, once for the results and once for facets). > > I'm still wrapping my brain around the UI approaches, but to summarize, it > seems that there are two main approaches you could take to exposing facets > to users: > > 1. Show facet values for the search including constraints (what you get if > you run search:search just once) > 2. Show facet values for the search without constraints (what > community.marklogic.com does) > > I'm assuming that when you say "even those with zero occurrences", you mean > #2 above. Otherwise, I'd have to add #3: > > 3. Additionally list all facet values in the search corpus that don't match > the given search at all (with or without constraints). > > To get #3, I guess you'd need to run search:search yet again with empty > search text to get a full list of all possible facet values in your search > corpus. > > If you weren't using the Search API, you could get the list of > zero-matching values by doing something like this (substitute > cts:element-values for a range constraint, etc.): > > cts:collection-match("category/*", "map") - > cts:collection-match("category/*", "map", "my-search") > > But since you are (and I am) using the Search API, you couldn't just do a > map difference (like the above). Instead, you'd have to identify the values > not already returned in #2 to know which of the facet values should have > "(0)" after them. > > This is the part where someone else comes in and says, "You're > over-complicating things, Evan. All you'd have to do in this case is XXX." > I'm all ears. ;-) > > Evan > > > On 5/10/12 4:30 AM, "Jakob Fix" <[email protected]> wrote: > > Hi, > > I'm doing the usual application where you have the facets listed on > the side of the search results and you can select from there one (or > more) to filter the results. > > However, search:search only returns the facet values for which it finds > hits. > > Is there a way to return *all* available facet values, even those with > zero occurrences? > > Right now the only way I've found is to call search:search twice and > then combine the result. > > cheers, > Jakob. > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
