Closed hackartisan closed 1 year ago
Through code read I believe I've summarized the current recommendations on https://github.com/projectblacklight/blacklight/wiki/Upgrading-to-Blacklight-8#plugin-upgrade-scenarios. Please make corrections there where required. For further discussion or alternate proposals moving forward please reopen this issue or create a new issue, or add an agenda item to the committer's call.
This issue serves as a record of discussion that took place on https://github.com/projectblacklight/blacklight/wiki/Upgrading-to-Blacklight-8. In order to clean up that page and present a succinct summary of the current upgrade recommendations, much of the discussion and comment was lost. It is pasted below.
Scenarios
Adding elements to "constraints"
render_constraints
orrender_constraints_filters
to callsuper
and concatenate their own additional content.super
.render_constraint_element
helper method, to say "render this constraint in whatever the application style is, even if it's been customized". That method is also no longer available.Blacklight::ConstraintsComponent
this used to berender_constraints
Blacklight::ConstraintLayoutComponent
this used to berender_constraints_element
Blacklight::ConstraintsComponent
ConstraintsComponent
class to a configuration variable and have the partial use that variable.blacklight_range_limit
,geoblacklight
, andblacklight_maps
all want to add an element to constraints.Change the way the "query" constraint is rendered
render_constraints_query
helper method -- this is no longer available.Blacklight::ConstraintLayoutComponent
), which is passed into the Blacklight::Constrains component: https://github.com/projectblacklight/blacklight/blob/fd33c74a378d164a571174fa0054c25b70ef09d1/app/components/blacklight/constraints_component.rb#L11 ; To customize, provide a different component.Render Constraints in a new page in plugin or app
render_constraints
to render the constraints including any customizations added by plugins or local app, as above.Blacklight::ConstraintsComponent
.Blacklight::ConstraintsComponent
-- this does not get customizations made by above suggestions to "provide a different component" forBlacklight::ConstraintsComponent
Proposal for above scenarios
After trying to wrap my head around the scenarios for a while, and let it role around in there... what if we provide some additional configuration variables, specifically targeted at these constraints-customizing use-cases? [I think this essentially a means of what they call "dependency inversion", via the blacklight configuration object].
There is a little step into the precedent of providing component classes in Blacklight configuration already exists in the BL 8 codebase.
For instance, a
document_component
configuration value (with default) is set here and here, and then referenced here and here.This way, an application (or possibly plugin) can set a
document_component
to a new component, via configuration, and have this new component be used by Blacklight... without the need to try to customize every single place that renders a "document_component" (which may require customizing the things that render the things that render a "document_component", etc).If we keep going with the idea of components in configuration to allow the specific use cases identified to be achieved in a precisely targetted way, we might have:
config.query_constraint_component =
Blacklight::ConstraintLayoutComponent
: Can be set to customize the query constraint as blacklight_advanced_search and some local applications doconfig.additional_constraints_components =
[]
: A default empty array, that you can add 0 or more component classes to, to add additional constraints. This way multiple different plugins can add something to this array, and have their thing rendered on the end of constraints area, without having to fight for control of theConstraintsComponent
or interfere with each other.Now a plugin that wants to render constraints can just render
Blacklight::ConstraintsComponents
, and still get all the customizationsBut how do all these things actually render the little boxes? Before they could call the
render_constraint_element
helper, to render a constraint element in a standard way -- that if a local app wanted to change that standard way by overriding that helper, the plugins would use the new changed standard way. Now... they can render the newBlacklight::ConstraintLayoutComponent
, but there's no way for an app to change what that does. Do we need aconfig.constraint_element_component
too, or is that getting too crazy?This plan does have some complexity downsides. And I guess the exact initialization arguments of each of these configurable components would have to become part of Blacklight API. As I guess is already the case for the
document_component
configuration.But this is the only reasonable way I've been able to come up with to support these use cases no worse than previous Blacklight. It is eg a very popular use case for plugins to want to add an element to the "constraints" area, and you might have multiple plugins all wanting to add their own element.