Closed (fixed)
Project:
Facet API
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
4 Aug 2015 at 08:38 UTC
Updated:
10 Sep 2015 at 18:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
drunken monkeyThe attached patch would implement this.
Comment #2
stefan.r commentedI can confirm this patch would be useful in solving the linked issue!
Comment #3
pwolanin commentedis FALSE better than NULL?
Just wondering if FALSE is a valid value for boolean facets?
Comment #4
stefan.r commentedFALSE can actually be used for boolean facets so let's go with NULL instead?
Comment #5
pwolanin commentedThat seems less likely to cause issues, and setting to NULL is pretty clear in terms of intent?
Comment #6
stefan.r commentedOK good, in manual testing there seemed to be no issues with this.
Comment #7
drunken monkeyI don't think that makes sense, no, since we're not talking about the values, but about the labels. And a non-string label doesn't make any sense – instead of
FALSE, you can still use''for the same effect (though I don't think many people will want that).We picked
FALSE, I think, because it feels more like an explicit "No!" instead of an "I don't care" whichNULLseems to imply (in my eyes – highly subjective of course).But of course, I'm fine with either. I just don't think there will be technical problems with either option.
Comment #8
stefan.r commentedI think currently in boolean facets the label can have the value FALSE in the map, which will get translated to 'no' upon printing to screen... whereas the previous patch would make any "no"s disappear altogether?
Comment #9
drunken monkeyAs said, labels are inherently strings, not booleans. I don't think there's anywhere where anyone sets
FALSEas a label. Please try to reproduce the problem and/or find code supporting your claim before just using it as an argument based upon pure conjecture. (Also, where would the magic be that automatically translatesFALSEto'no'when printing?)But, as said, I'm fine with either solution. If you both like
NULLbetter, please just commit that version and we'll change the patch in #2479399: Facet API integration still allows filtering on access-controlled/unloadable entities accordingly.In any case, thanks for your feedback, Peter! (But you don't have commit access either, right?)
Comment #10
pwolanin commentedI have had commit for a long while https://www.drupal.org/node/808232/maintainers
Comment #11
pwolanin commentedDoes this need to be ported to 8.x?
Comment #13
drunken monkeyAh, sorry! You aren't listed on the project page, and I thought that lists all the people with commit access. (I can't access the "Maintainers" tab and this list mentions everyone who contributed a patch, too.) Then I guess there's no way to see who has commit access for non-maintainers? Strange …
Anyways, thanks for committing!
And no, the D8 version is a) a complete re-write and b), as far as I know, not very far yet, so we don't need to port this.