|
JavaFX Support in Lobo Web Browser
Lobo 0.98+ [download]
can directly render compiled JavaFX Script source files.
Lobo treats JavaFX
as a first-class citizen, in much the same manner it treats HTML. This means that:
- The JavaFX deploy-test cycle in Lobo is quicker and more convenient. There is no need to pre-compile and package JavaFX code or use HTML pages.
- The source code of a JavaFX script is available for browser users to examine.
- JavaFX code in Lobo has access to various capabilities of the browser and
can be more web oriented.
- JavaFX code can be generated by server-side technology such as servlets, JSP, PHP, RoR and others.
- JavaFX scripts loaded by Lobo are potentially indexable by search engines.
Requirements
JavaFX support in Lobo requires
JRE 1.6+, even
though the browser itself only requires JRE 1.5+.
JDK Note: Currently the browser must run on top of a JRE, and not a JDK.
The Java Compiler API is bypassed in favor of patches made by the JavaFX
compiler team.
JavaFX Version
Lobo 0.98 relies on the weekly build of the JavaFX compiler and runtime
released on 02/11/2008. It should be noted that this is still early
stage (though remarkably good) work by the JavaFX compiler team.
Security Restrictions
JavaFX/Java code loaded by Lobo from a remote location
is run with security
restrictions equivalent to those of an unsigned applet.
Note, however, that Lobo provides capabilities that are
not currently available to applets, such as
managed stores.
MIME Type
The MIME type of a JavaFX script is expected to be text/x-javafx-source,
but other MIME types like application/octet-stream and text/plain
will work provided the URL ends in .fx.
API Available to JavaFX Code in Lobo
A JavaFX script loaded by Lobo should be assumed to only have access to the following APIs:
- Java Platform SE 6 API.
- Lobo Extensions and Clientlets API (lobo-pub.jar).
- The compiled JavaFX runtime API.
- Classes from locations specified in the
classpath or sourcepath directives (explained below).
Directives
Java/JavaFX "pages" in Lobo use standard Java/JavaFX syntax. You can,
nevertheless, add a special comment that contains
compilation and rendering directives for Lobo. The comment starts with /*!
and ends with */. The content of the comment should be in
property-file syntax, except an asterisk is allowed at the beginning of
every line. Directives (properties) understood by Lobo, all optional, include:
- title: The title of the "page". This should be the
window title when the page is rendered, and it's
also used in history lists and so on.
- description: A description of the "page". This is saved along
with Lobo bookmarks and is potentially indexable
by search engines.
- sourcepath: A list of comma-separated URLs required to locate other source files during compilation.
- classpath: A list of comma-separated URLs, typically JAR file locations,
required by the "page" at run-time.
- sourcelist: If
sourcepath contains URLs ending
in slash (directories instead of JAR files) this property should contain a
list of comma-separated file paths required during the build of
the main compilation unit. A file path consists of the package name, with its dots
replaces by forward slashes, followed by a forward slash and the file name,
e.g. com/acme/package/File.java or com/acme/package/File.fx.
- classlist: If
classpath contains URLs ending
in slash (directories instead of JAR files) this property should contain a
list of comma-separated file paths required during the build of the main
compilation unit. A file path consists of the package name, with its dots
replaces by forward slashes, followed by a forward slash and the file name,
e.g. com/acme/package/File.class.
Clientlet Context Access
A request-response thread in Lobo has access to the current
ClientletContext
instance, obtained by calling ClientletAccess.getCurrentClientletContext().
This can be used by scripts to perform various browser tasks, such as navigating
away from the page, opening alert windows, making requests through Lobo, creating
browser frames, or accessing
managed stores.
What is Rendered
Obviously, only certain classes can be rendered: Those that
can be assigned to java.awt.Component (including
javax.swing.JComponent) plus any JavaFX classes
with a getJComponent method, such as javafx.ui.Canvas;
plus those that can be assigned to java.awt.Window.
Programmatic use of Lobo
We have a Browser API (GPL) that will
load Java/JavaFX code, much like it loads HTML, provided the
pertinent browser extensions are available at run-time. This means
a Swing application can embed Lobo and load remote JavaFX/Java code via
the Lobo API.
Examples
The following examples are not intended to teach the reader about
JavaFX syntax or capabilities. For that
you might want to visit Jim Weaver's Blog.
These are examples of some things you can do in Lobo with JavaFX.
- JavaFX Redirect.
You have probably heard of a HTML redirect. This would be
a JavaFX redirect in Lobo.
JfxRedirect.fx
- Lobo Frame in JavaFX
At this point we don't have a JavaFX-based API for Lobo,
but it is possible to add AWT/Swing components obtained
from Lobo's Public API and embed them in a JavaFX GUI.
The following example shows how to embed a Lobo browser
frame.
LoboFrameInJFX.fx
The following is how LoboFrameInJFX.fx renders
in Lobo:
- Managed Store Demo.
The following example involves a simple text area with a "Save" button.
Text is saved to a client-side file in the managed
store for a given host name (lobobrowser.org
in this example). Whenever this example
is opened in Lobo, text previously saved is
placed in the text area.
PersistentTextPad.fx
Feedback
If you have successfully tried Java or JavaFX code in Lobo, feel free to
post your source code URLs at the
Open Discussion Forum.
If something doesn't work quite right in Lobo's support
of Java/JavaFX, please use the
Help Forum
to tell us.
See Also
External Links
Support The Project
|