BriskBard, CEF4Delphi, WebView4Delphi, WebUI4Delphi and WebUI4CSharp

I've been writing a non-visual automated screen scraping applications using TChromium in OSR mode but without displaying the rendered HTML output anywhere. My next project will be more visual and will allow the user more interaction with the browser, so I'll need to explore other areas of the CEF4Delphi library.

I'm interested in hearing about your Briskbard browser as an example of best practice CEF4Delphi usage. If you're happy to share I'd love to hear about the architecture of your Briskbard browser and how it makes use of CEF4Delphi. Specifically I'm wondering:

• Do you have just one TChromium component in the whole Briskbard or do you have a TChromium per window or per tab?
• Do you use TChromium in OSR mode? If so what component do you use as your render surface?
• Do you use the Views framework?
• Which of the demo applications has the most similar architecture to Briskbard?
• Would you change any of the above design decisions if you were starting again today?

Thanks very much,

Lachlan

LachlanG wrote: ↑Thu Nov 19, 2020 4:22 amDo you have just one TChromium component in the whole Briskbard or do you have a TChromium per window or per tab?

BriskBard uses one TChromium component per tab but that can be optimized and it will probably be chaged to one TChromium component for all the tabs in the future.

LachlanG wrote: ↑Thu Nov 19, 2020 4:22 amDo you use TChromium in OSR mode? If so what component do you use as your render surface?

BrisBard doesn't use the OSR mode. Only "normal" mode.

LachlanG wrote: ↑Thu Nov 19, 2020 4:22 amDo you use the Views framework?

I still have to fix a problem with the Views Framework in CEF4Delphi in 32 bits before considering if it's worth the effort.

LachlanG wrote: ↑Thu Nov 19, 2020 4:22 amWhich of the demo applications has the most similar architecture to Briskbard?

Perhaps the TabbedBrowser2 demo but BriskBard uses a lot of custom components created at runtime (including the tabs) which makes this a distant similarity.

LachlanG wrote: ↑Thu Nov 19, 2020 4:22 amWould you change any of the above design decisions if you were starting again today?

The current design works very well at this moment but it will probably change to one TChromium component for all the tabs.

salvadordf wrote: ↑Thu Nov 19, 2020 9:29 am BriskBard uses one TChromium component per tab but that can be optimized and it will probably be chaged to one TChromium component for all the tabs in the future.

That's surprising to me.

I'm assuming your Briskbard architecture is something like TForm contains TPageControl with dynamically created TTabSheets each containing a TFrame that contains a TChromium. That sort of design would let you nicely encapsulate all the browser code inside the TFrame and the TChromium on that TFrame will only refer to the browser window on that frame.

If you move to a single TChromium for the whole application, say via a shared TDataModule, won't you need to do a bunch more work to keep track of BrowserIds and ensure that you're always using the correct browser from that TChromium?

Plus you'll only have a single set of event handlers, and any event that fires could be for any of the tabs. It sounds like a much more complicated architecture for your application code at least.

What are the benefits of having a single TChromium?

You're right. Having one TChromium per tab is much less complicated however, trying to replicate what the official CEF demo do usually gives better results and it shares the handlers for main browser and the popup windows.

I wouldn't be surprised to see that the new "Chrome runtime" requires a shared TChromium to handle all browsers.
https://bitbucket.org/chromiumembedded/ ... -callbacks

Right now the Chrome runtime is in experimental state and I'll take a final decission about this once it's finished.