- Code: Select all
class ClientHandler : public CefClient,
public CefContextMenuHandler,
public CefDisplayHandler,
public CefDownloadHandler,
public CefDragHandler,
public CefGeolocationHandler,
public CefKeyboardHandler,
public CefLifeSpanHandler,
public CefLoadHandler,
public CefRequestHandler
While I understand that these classes are just interfaces, there's still the problem of this rigid relationship between the ClientHandler and the individial Cef*Handler classes. Let's say you want to implement various chromium controls in your application, each with a different Context Menu Handler or Keyboard Handler, you would have to reimplement the whole thing, even though some components might be shared (such as the lifespan handler for example).
Do you see any downside to implementing the ClientHandler as an entity with Cef*Handler components? Something like this:
- Code: Select all
// We keep this, in order to meet the interface requirements;
// however, it will only be a single class in the entire application
class ClientHandler : public CefClient,
public CefContextMenuHandler,
public CefDisplayHandler,
public CefDownloadHandler,
public CefDragHandler,
public CefGeolocationHandler,
public CefKeyboardHandler,
public CefLifeSpanHandler,
public CefLoadHandler,
public CefRequestHandler
{
public:
// example: CefContextMenuHandler
void AddComponent(CefRefPtr<CefContextMenuHandler> handler) {
m_menuHandlerComponent = handler;
}
bool OnContextMenuCommand(...) override {
m_menuHandlerComponent->OnContextMenuCommand(...);
}
private:
CefRefPtr<CefContextMenuHandler> m_menuHandlerComponent;
}
And then, you'd be able to mix and match CefContextMenuHandlers for different controls. Same goes for the other handlers.