#1802750: [Meta] Convert configurable data to ConfigEntity system is tracking converting all configuration that has multiplicity into the ConfigEntity system. I.e., image styles, text formats, views, account email templates, etc. are all examples of things that different sites can have different sets of, which requires the "C" and "D" part of CRUD, and in general, fits the concept of entities (in the broad sense of the word, not the more limited D7 sense).
However, we also have configuration objects like system.site.yml, for which every site only ever has 1 of. So far, consensus has been that these should not be ConfigEntities. One of the consequences of that choice is that configuration translation requires a completely separate concept/implementation/API/UI than entity translation.
In #1648930-129: Introduce configuration schema and use for translation, fago says:
I could see the simple settings being each own config entity as well.
Let's discuss that in this issue.
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedBy the way, I'm currently leaning to "no" on this, because using the entity system for singular-only objects feels architecturally wrong and cumbersome. But I'm open to being persuaded otherwise.
Comment #2
sunComment #3
tim.plunkettThe 4th and 5th point in #2 are why I think this should be won't fix.
Comment #4
gdd#4 is one of the keys to why this is bad, because settings files absolutely can not be deleted unless their module is uninstalled. The results of this happening are pretty catastrophic. I agree there aren't really any commonalities and this is won't fix.
Comment #5
sun#2 only compares the two architectural concepts.
It does not imply that there couldn't be Settings next to Configurables.
Comment #6
tim.plunkett@sun, we've continued to use "Configurables" as an issue tag, but it does not actually refer to anything in core, and I'm confused.
What are you suggesting? Another class, similar to ConfigEntityBase, also extending from Entity? Or reusing ConfigStorageController somehow?
Comment #7
sunThe differences outlined in #2 would clearly require a dedicated entity base class and a dedicated storage controller. Nothing inherited from the current Config\Entity* classes.
Settings would still be entities though, and they could re-use all the entity/property system facilities. They would present a sorta new term of "universally unique entities."
Comment #8
sunTo clarify further: The comparison in #2 left out what Settings and Configurables actually have in common:
langcode
, because at minimum, default configuration ships in English.module
, because all settings are owned by some extension.api
version, because available settings and their possible values can (and do) change over time.If you'd task me to do this today, then I'd probably investigate the following first:
Config\Entity\Settings extends EntityNG
with accompanying storage controller (see #2).Config\Entity\SettingsFormController
that handles a settings form.UserAccountSettings extends Config\Settings
and go the hard way.Comment #9
effulgentsia CreditAttribution: effulgentsia commentedRetitling accordingly.
Comment #10
fagoAlso related: #1818574: Support config entities in typed data EntityAdapter:
Exactly. In particulary that they exist only once and must not vanish is what does not make them very entity like.
ad #8: Sounds reasonable, but how to approach the mentioned problem?
I was thinking about something like that:
- Making "settings a single entity type with the settings name "module.settings.bla" being the entity id.
- If you load the entity it gets the default settings file, or a settings files containing the change if existing.
- When saving the entity, it writes a new non-default settings file.
- When deleting the entity, it deletes the changes file only - so load continues to work with the defaults. (revert)
That's my brainstorming on that, not sure that would play with CMI and whether we it's something we really should pursue... It would have some nice advantages for us though.
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commentedHi, I was wondering whether there is any progress with this one, I mean one way or another a decission needs to be made, and maybe in the last month people have made up their minds about this. Or if not, should we toss a coin? ;-)
Also I am concerned about the implications this has for ConfigEntityBase and translatable properties in general:
And btw, wondering whether we've got an issue created for that @todo.
This is also a major concern now the 'config/metadata/translation' approach for the locale system has somehow 'derailed'. So I'm wondering whether you guys have an alternate plan about this...
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedI think sun's suggestion in #8 is cool in theory, but I chatted about it with chx, who brought up the point that a good number of our singular config objects have values that are accessed in performance-critical parts of the code. Wrapping those up in any further abstraction could be too costly. If someone wants to submit a patch for #8 that demonstrates how it's not a performance problem, then ok, but given the lack of work on this to date, my current guess is that this is unlikely to happen for D8.
Well, chx is working on an idea in #1861640: Provide config metadata solely for translation, but I still haven't given up on #1648930: Introduce configuration schema and use for translation: contrary to #312 of that issue, I still really like the TypedData aspect of that issue, and am still exploring how that could be retained. If others here have other thoughts, please share them as well.
Comment #13
sunMy immediate and very simple answer to that would be to not use config entities when they are not strictly required.
In other words: Config entities are a high-level instrument to manage and operate on a particular config entity/object.
However, that does not inherently imply that anyone has to bootstrap a config entity to read a config object.
The contextual override logic upon read is handled in a different (low-level) layer of the config system anyway and is not tied to config entities anyway.
In short, read != write.
Perhaps a path to investigate.
Comment #14
gddIt seems at this point that we aren't going to do this, which I agree with, so closing. Feel free to reopen if someone wants to get back into this topic at some point.