|
|
The jXUL Layered Architecture
The jXUL architecture is composed of vertical and horizontal layers. The separation allows
for abstractions to be limited to small functional areas. Such small abstractions are
more easily understood, more easily mixed and matched and more easily implemented. A description
of each layer is below.
Each Layer will have its own Java package. Here is a list of the current packages:
- org.jxul.applet
- org.jxul.css
- org.jxul.framework
- org.jxul.js
- org.jxul.xulrunner
- org.jxul.util
- more on the way...
- Xul Widgets
- Each XUL element is represented with its
own class that extends an existing Swing JComponent. These classes will be instantiated
either from a DOM Element or a text fragment from a XUL file.
- CSS Styling
- A set of classes representing CSS
Stylesheets, CSS Styles and the ability to apply these styles to XUL widgets.
- JavaScript Engine
- Supports XUL applications by embedding
the Rhino JavaScript interpreter. Secondly, a package (js) will be created to
represent the translation of JavaScript built in objects (like document and
window) into their Java GUI counterparts.
- XBL (The eXtensible Binding Language)
- To Be Delivered (TBD). This part has not yet been
designed. Your suggestions are welcome.
- Xul Runner
- Modeled after the AppletRunner. This Java
program will run complete XUL applications (allowing scripting in JavaScript). The
goal is to allow a XUL application to be shipped as a standalone java program. The
Xul Runner will start out by parsing a XUL XML file and creating a DOM. The DOM
will be traversed and XUL widgets will be created. Every XUL Widget (subclass of
JComponent) will be associated to its corresponding DOM node in a peer map. If a CSS
file exists, it will be parsed and CSS Style objects and a CSS Stylesheet object
created. That Stylesheet will be applied to the Xul-DOM. Lastly if a JavaScript
script exists, it will be parsed by Rhino and linked to the Xul-DOM by way of
proxy objects. Lastly, (not yet implemented) all JavaScript fragments that act
as event handlers will be registered with their associated JComponents in the
peer Map.
- Xul Applets
- TBD. Again, your suggestions are welcome.
- Xul Fragment Factory
- Parsing of a text fragment that describes a single XUL widget will
generate a instantiated Xul Widget object. If the Xul fragment is a container it will be
allowed to have child elements. Appropriate event handlers will be passed into the
factory method at instantiation.
- Swing Resources
- Additional requirements for this need to be
collected. Your input is needed! What would you find useful?
- Xul Applications
- Another key requirements for XUL applications
will not only be able to run them on the Java platform but be able to debug them.
A very ambitious goal is to be able to step through the XUL file, line by line, to
properly debug it. This will be extremely helpful to XUL hackers.
| |
