CEF Forum

I find that there's a small issue with the design of CefClient and the way in which it is intended to be used. Here's the example in the cefclient sample app:

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.


palaver wrote: find that there's a small issue with the design of CefClient and the way in which it is intended to be used. Here's the example in the cefclient sample app:

Have you looked closely at `CefClient`? `CefClient` allows for a composite design, it's really just a class factory after all (Other than the message handling).

If you require a truly modular design then you can have a single class that implements a single interface, or multiple, or whatever you choose.

https://bitbucket.org/chromiumembedded/ ... lient.h-69

Is there a special requirement you have for implementing `CefContextMenuHandler` twice? Seems unnecessarily complex to me.

Have you looked closely at `CefClient`? `CefClient` allows for a composite design, it's really just a class factory after all (Other than the message handling).

Admittedly I haven't, but having looked at it, I see how it allows for composite design.

Is there a special requirement you have for implementing `CefContextMenuHandler` twice? Seems unnecessarily complex to me.

I'm implementing a reusable Chromium Control library for use in several applications, and I'm trying to abstract away as much of the lifetime management as I can, since it's effectively just boilerplate. The implementer would then implement their own CefContextMenuHandler, etc if needed and simply feed them to the client handler whenever necessary. This is also useful if the same application has multiple chromium controls, each with different purposes. You could also argue that we could implement those context menus in JS, but then that would not be consistent with the remainder of the application, which has other native controls. Now carry this example over to other Cef*Handlers, and hopefully my intent is clear. Needless to say, I welcome any other better approach, that's why I asked the question.

Do you miss CefClient's methods like GetContextMenuHandler which can return 'component'? No one force you to put all eggs into one ClientHandler class.

There is usually no have any sense to have one CefClient object which can handle different types of browsers. You always can construct multiple CefClient objects as many as you need, and pass them to browser (when creating), and this clients should be composed with right parts, so you will not needed to dynamically choose actual handler each time.