https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37054
--- Comment #80 from David Cook <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
