Coverbrowser: event for cache refreshing #10956
Conversation
| if ui.coverbrowser then -- refresh cache db | ||
| ui.coverbrowser:deleteBookInfo(file) | ||
| end | ||
| UIManager:broadcastEvent(Event:new("DeleteBookInfo", file)) -- refresh coverbrowser cache db | ||
| UIManager:broadcastEvent(Event:new("BookMetadataChanged", self.prop_updated)) |
There was a problem hiding this comment.
I seem to remember you told me deletebookinfo had to be done before bookmetadatachanged - which is what is happening here :) but couldn't it be done in the same BookMetadataChanged event ?
Also, no better name than DeleteBookInfo for this event ? DeleteBookInfo will be the specific action the coverbrowser plugin will do - but no other thing will act on this event. With a more generic name, like BookMetadataAboutToBeChanged (or something nicer :), coverbrowser would delete book info, but other code/pluging could do something else.
There was a problem hiding this comment.
couldn't it be done in the same BookMetadataChanged event ?
I do not know how to arrange the required order of event handling by different modules.
There was a problem hiding this comment.
Oh, right, that was the reason.
No idea either, and having 2 events is probably the right solution.
I just feel it needs a better name BookMetadataPreChanged, BookMetadataAboutToBeChanged ...
There was a problem hiding this comment.
I cannot find other good idea for the name.
The event is specially for CoverBrowser, sent after metadata changed.
There was a problem hiding this comment.
BookMetadataObsolete ? BookMetadataStalled ?
(meaning: the things you may have are now invalid - another event will come soon with what's been updated)
There was a problem hiding this comment.
If it's a cache we're talking about, the usual technical term to trash it because it no longer matches live data is "invalidate"; so InvalidateMetadataCache (I think document/book is fairly obviously implied there and can be elided ;)).
There was a problem hiding this comment.
I like InvalidateMetadataCache but the general question is: should the event name show what happened or what should be done?
There was a problem hiding this comment.
It should express what happened, when something specific happened, so handlers can do the different things that they think should be done after than specific thing happened.
In some cases when no specific thing happened and it's just a continuation of some handling, the event can be an action (ie. UpdateToc, UpdateFooter).
I like InvalidateMetadataCache too.
Self-explained.
This change is