Concepts and Design
From a software layer perspective, the XOE framework is implemented as a pure Java class library, sitting on top of a PersonalJava 1.2a runtime environment. This ensures both platform (OS) independence as well as compatibility with existing Java Applets. The major purpose of the framework is to provide the infrastructure required by XOE applications - small conglomerates of web-pages and servlets, which can be installed on demand.
A typical XOE application is composed of the following parts
one or more standard XHTML documents containing the view specifications and static display data
a Servlet containing the logic for both control events and FORM actions of the application
XML defined data, which is accessed from the Servlet via XPath queries into a abstract repository holding DOM trees
XOE applications do not require any new language or document format. They are distributed as XOE packages stored in jar files, and are described by means of XML meta data.
Consequently, the key design elements of the XOE system are so called local services and the package management subsystem.
Local services are the backbone of the XOE architecture, they consititute the major component to achieve its extensibility. Even though local services can come in a variety of types (which implement the IService interface), typical application services are Servlet instances containing logic and control of XOE applications. They can be triggered by:
control events (onClick, onFocus, onKeyDown etc.)
FORM submits (i.e. the Servlets contain the FORM actions)
requests from other services
Since these service objects all live in the same process, they can interact with each other, and the rest of the environment (exchange data, switch view documents, return to previously viewed documents, set content of view elements etc.). The aspect of being locally executed make these services more powerful compared to their server-side counterparts, which can only be used to modify server-side data and/or return new documents.
Local services can access the whole framework, i.e. they don't share the same limitations like document scripts (which usually work by means of get/set side effects for DOM-0 attributes of the browser and displayed document). This makes it even possible to use local services for rendering purposes, which are out-of-scope for most scripting languages.
Developers only have to deal with one mechanism and language, which also enables them to easily interface with other Java components, or even native libraries. Since these services can be standard servlets, there is a straightforward migration path for classical server based web applications. The mechanism which is used to communicate between view elements and services is not restricted to local operation, but can also be used to access classical remote services.