Facet API is introducing dependency plugins as a means to solve the issue #551620: Type dependent facet blocks. Apache solr will have to associate the correct plugins with the various fields in order to utilize the new functionality.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | apachesolr-1157864-9.patch | 1.06 KB | cpliakas |
| #4 | apachesolr-1157864-4.patch | 1.42 KB | cpliakas |
| #1 | apachesolr-1157864-1.patch | 1.36 KB | cpliakas |
Comments
Comment #1
cpliakas commentedThe attached patch integrates with the dependency plugin system. Marking as needs review, however this can wait until the dependency-551620 feature branch has been merged back into the 7.x-1.x branch. If we wanted to jump the gun and committed it now, it wouldn't break anything.
Comment #2
cpliakas commentedComment #3
cpliakas commentedThis dependency feature branch has been merged into the main 7.x-1.x branch of Facet API, and this patch is still valid.
Comment #4
cpliakas commentedUpdated patch to work with #1158594: Implement the "referenced" dependency setting.
Comment #5
pwolanin commentedre:
So facetAPI altering the field info, or that needs to come back from the apachesolr hook invocation?
Comment #6
cpliakas commentedSince Apache Solr is defining the fields, Apache Solr is responsible for associating the dependency plugins with the fields. Only it knows the types of fields it is defining, and when they get to Facet API is has no concept of where the underlying data came from.
Comment #7
cpliakas commentedChanging tag so we can more accurately track Facet API integration issues.
Comment #8
cpliakas commentedI added the "role" dependency so that users can configure which roles can see certain facets at 5b07200. I am marking as "needs work", because I am thinking that all fields should have the "role" and "bundle" dependency plugins. Reading up on progressive disclosure, I think that we should give administrators as much flexibility as possible configure the conditions that expose facets.
Comment #9
cpliakas commentedRe-rolled patch with support for the "role" dependency plugin. Added both "bundle" and "role" dependency plugins to all fields, since it will give users maximum amount of configuration in terms of which facets are displayed to the user when.
Comment #10
pwolanin commentedLooks like a very minimal change - though what do you need the field name for?
Comment #11
cpliakas commentedThe name serves a couple of purposes. First, it tells you what field you are dealing with so you can load the definition and get information such as the bundles the field is attached to. This is important for the "A content type this field is attached to must be active." setting. I'm sure this information will be useful in other cases that we haven't thought of yet as well. Second, it tells you whether or not a field is a Field API field. In cases such as the nid, the "A content type this field is attached to must be active." setting wouldn't make sense so it knows to not display the option. Without this key, neither would be possible without more complex logic.
Comment #12
pwolanin commentedcommitted.