Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use common partials for public resource browses #2240

Open
zerocrates opened this issue Nov 27, 2024 · 1 comment
Open

Use common partials for public resource browses #2240

zerocrates opened this issue Nov 27, 2024 · 1 comment

Comments

@zerocrates
Copy link
Member

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.

@zerocrates
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant