You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a handful of places where public-side resource browsing happens: the browse pages themselves, the browse preview block, the Faceted Browse module (when not using columns it uses a standard browse display), and now Hierarchy. This creates duplication in the themes and modules, and leads to a situation where themes customizing the browse get inconsistent appearance with the modules, or have to override the module views to make things consistent, and thus become harder to maintain.
We could introduce a partial (or partials) for the browse contents and use them in the various places the core does browsing. Modules wanting to have a browse of resources could also use the same partials, and themes customizing them could customize the partial and thereby customize all places it's used without having module specific code in the theme.
A single partial around the whole browse loop could work for this, but we might want to additionally separate out the inner portion used to display just one resource's summary: this could allow keeping the outside browse containers and structure the same between all resource types but have different "summary" partials for each type, further reducing duplication. The partial for displaying one resource summary could also potentially be used on its own, perhaps in a block.
This shouldn't cause a BC issue: if introduced in a mid-series update, we'd alter the base views to use this structure instead of monolithic browse views, and modules could depend on that version if they alter their views to use them as well. Old themes that have their own browse views would not gain any benefit until/unless they were updated, but would still work correctly.
The text was updated successfully, but these errors were encountered:
One item not squarely addressed above but relevant to the discussion is the feature in many themes of an optional toggle between list and grid views for browses: this is one of the most visible common browse customizations.
A common browse partial as discussed above could contain that customization, but we might also consider upstreaming the feature into the core, so the "standard" browse across themes would have access to that feature. Settings that are currently theme settings for controlling if the view is list, grid, or user-selectable and if so with what default choice, could move to being site settings if we made such a change, but we'd have to consider how that would interact with old themes.
We have a handful of places where public-side resource browsing happens: the browse pages themselves, the browse preview block, the Faceted Browse module (when not using columns it uses a standard browse display), and now Hierarchy. This creates duplication in the themes and modules, and leads to a situation where themes customizing the browse get inconsistent appearance with the modules, or have to override the module views to make things consistent, and thus become harder to maintain.
We could introduce a partial (or partials) for the browse contents and use them in the various places the core does browsing. Modules wanting to have a browse of resources could also use the same partials, and themes customizing them could customize the partial and thereby customize all places it's used without having module specific code in the theme.
A single partial around the whole browse loop could work for this, but we might want to additionally separate out the inner portion used to display just one resource's summary: this could allow keeping the outside browse containers and structure the same between all resource types but have different "summary" partials for each type, further reducing duplication. The partial for displaying one resource summary could also potentially be used on its own, perhaps in a block.
This shouldn't cause a BC issue: if introduced in a mid-series update, we'd alter the base views to use this structure instead of monolithic browse views, and modules could depend on that version if they alter their views to use them as well. Old themes that have their own browse views would not gain any benefit until/unless they were updated, but would still work correctly.
The text was updated successfully, but these errors were encountered: