Changes in the entry editor mark the database as dirty#2997
Conversation
|
I'd say this is a hack. Whereas it is better than missing a changed state for now, we should only mark the DB as dirty if we really changed something. |
|
I'm also not very happy with this solution from an architectural view: why should the gui handle the dirty/clean state and not the logic? I would propose to add listeners to the database/metadata in |
|
The databaseChangedEvent is already realized with the EventBus system, so it just needs a couple of listeners if I understand it correctly. And one event bus can have multiple listeners for the same event |
|
Ok, I see. So far it had been implemented only in the BasePanel, but I aggree that the cleanest solution is probably to track it in the database itself. This won't be as quick as the current solution, though :) The consensus seems to be that we are not going in this direction, so I'll close this PR. |
Partial fix to #2787
Changes in the entry editor now mark the database as dirty. This are somewhat proactive: even only opening the entry editor will mark the database as changed. I'd say this isn't a problem. I'd rather have it do the marking than forget one.
Essentially, this adds another listener to the properties in the entry editor that propagates the change whenever the property changes. I haven't figured out how to do this for groups.
gradle localizationUpdate?