https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37054 --- Comment #80 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #77)
I’d like us to stop adding columns to core entities like `branches` for presentation or rules-related settings.
Agreed. As I said on Comment 54 the `branches` table should just have attributes of the branch/library resource.
* Mixing business data (branches) with presentation/styling data (like CSS) breaks the MVC principle. * Styling concerns belong in the front end (or a dedicated configuration layer), not in the core database model.
Even in the API, putting style info directly on the branch object feels out of place. It should be returned as an embedded resource or sub-object, not part of the core representation.
I think that these are good points too. As Tomas says, the issue becomes clearer when designing/using the API. If we think of the staff interface and OPAC as "reference implementations" of Koha interfaces, a lot of the presentation logic is unique to those interfaces, and has nothing to do with the core library data that Koha manages. For instance, they wouldn't be relevant for a Discovery layer or a third-party interface.
It’s perfectly fine for styling data to live in the database — but why not use a dedicated table?
And you know what’s coming next: someone will want a global default that can be overridden at the library level. Boom — another syspref gets added. We’ve seen this pattern repeatedly: a quick fix becomes permanent and clutters our model.
Y’all know I’ll eventually rant about the `configurations` table again, but seriously — this is exactly the kind of case where we should stop being pragmatic and start doing things the right way.
I suppose we could all argue over what "doing things the right way" means, but I do like the idea of a separate table. Looking back over my latest comments on bug 26129, I can see that I think `configurations` table might be too generic. But... I'm open to the idea. The cool thing about the `configurations` table is that if we decided later it wasn't 100% to purpose it would be easy to migrate to something more specific as well. Personally, I think the idea of a `ui_branches_themes` or `ui_themes_branches` might be an idea. We could move "OPAC information", "Specific OPAC JS", and "Specific OPAC CSS" to that table. If we give each theme a file-system friendly name, we could potentially map this to the filesystem so that libraries could easily link in JS and CSS files as well. -- You are receiving this mail because: You are watching all bug changes.