Affects Version/s: current
Fix Version/s: None
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Operating System: All
Jdic is great, but currently there is an implicit assumption, that there are
only two potential embedded browsers (IE and Mozilla) and that embedding one of
them will be successful.
This is a problem for cross-platform applications that want to use Jdic. They
may need to fall back on other browsers (e.g. a pure Java Browser, some other
embedded browser, a JEditorPane, or a custom solution) for cases where Jdic
provides no browser or where Jdic is not able to launch the presumably existing
default browser. Thus cross-platform applications need to add their own logic
for deciding when to use Jdic and for checking whether Jdic is successful.
To eliminate these problems, I would like to propose a refactoring of the
current browser package. It is not hard and I would be willing to do this.
The basic approach would be as follows:
Use a factory pattern. Introduce a
BrowserFactory interface and default implementation.
The BrowserFactory would be responsible for creating a Browser instance by
delegating to a BrowserEngine. Each browser type (Mozilla, IE, or others) would
have their respective engine. BrowserEngines can be registered and unregistered
from the BrowserFactory. BrowserEngine instances are able to determine whether
their browser component is available in the current environment, they have
specific information about that BrowserComponent (e.g. binary file, version,
etc.) and they can create a browser instance.
When a BrowserFactory is created, it loads its list of BrowserEngines. An
application can add its own engines to the factory or replace engines with newer
versions. When a new web browser instance needs to be created, the
BrowserFactory queries its registered BrowserEngines as to whether they are
available (this happens only the first time). The default implementation of
BrowserFactory would determine the default browser, check if an associated
BrowserEngine is available and then ask that BrowserEngine to return a new
browser instance. If the default browser engine is not available it would use
the first other BrowserEngine for which a browser component is available. But
other implementations might use different approaches.
The WebFactory could also be used to query the different BrowserEngines to see
which is/are available before actually instantiating a browser.
Using a factory approach simplifies many things. It would make Jdic even more
open, more flexible and would make it much easier to add support for more