![]() |
|
|
This brief document proposes an XML
application for describing user interfaces. This general purpose XML application
can be used in a variety of situations, but is especially intended for
use in future versions of the Navigator based on Raptor. As such, a description
of the binding between XUI and Raptor is also provided.
Or rather, why not pure HTML? A simple set of criteria were used:
NOTE: It is expected that subportions
of the UI can and will be expressed as HTML which will occur as embedded
tags within the XML. But the highest level structures most likely will
not.
To effectively construct a contemporary
UI in XML (or any other schema), it is necessary to provide sufficient
richness to describe the manipulatable elements, content, layout and constraints,
behaviors and style. The remainder of this section of the document represents
an attempt to define such a schema.
The minimum set of controls includes
static and editable text controls, buttons (push, popup, radio, checkbox),
toolbar, listview, treeview, menus (standard and popup), splitter bars,
scrollbars, status bars, spinners and tooltips. A brief schematype is provided
for each below:
In the XUI universe, we expect content to come from three sources:
This approach assumes that Raptor
itself will provide the constraint-based layout process used to handle
the layout of the user interface. In particular, it is expected that Raptor
tables will be used, albeit with a few minor modifications.
Behaviors come in intrinsic and extrinsic forms. Intrinsic behaviors refer to the inherent behaviors found within a given UI contol. For example, a tree control inherently offers selection, scrolling and expand/collapse of nodes. Extrinsic behaviors refers to programmatic behaviors that are constructed at runtime. These behaviors typically bind a known event within a control to an external observer that is notified upon with each occurance of that event. It is anticipated that event notification will occur either via notification interfaces or through the use of Javascript. <insert information about extrinsic
properties here...>
This model assumes that style is
bound to both manipulatable elements and behaviors either via CSS selectors
or through direct stylistic attributes encoded within the appropriate tags.
This section of the document will briefly describe all the processes involved in consuming, storing, laying out and rendering of an XUI/XML document. Step 1: Consume the XUI document As with any content type, a XUI document is identified during the parse process by XUI-DTD. Once bound, the XUI-DTD coordinates the parse/tokenization process. Text from the XUI document are parsed into the appropriate tokenset and given to the XUI-DTD for further processing. This step is trivial, and examples already exist within the Raptor framework that demonstrate this capability. Note that the entire XUI element tree is cached by the XUI-DTD for further processing. This is unlike the normal content production process, where little or no caching occurs. It is anticipated that very little performance impact will be detected since XUI documents will typically be very small. (See the example at the end of this document). Step 2: Transform the XUI elements into HTML One the XUI tags have been parsed into tokens, the XUI-DTD then performs an analysis and transformation phase. The XUI elements are converted into the appropriate set of corresponding HTML elements where possible. The transformation rules are inherent in the XUI-DTD, rather than by a corresponding XSL-type process. Step 3: Update the Separate UI content model The HTML elements produced by the XUI-DTD element transformation are sent from the DTD via the appropriate protocols to the HTML content sink. Because we begin all such transactions with a call to OpenUserInterface(...), the content sink can easily tell that it is receiving UI content. Subsequently, the UI content model can be kept separated from the main document content model. After the UI elements have all been sent to the sink, the DTD will notify the sink via the CloseUserInterface(...) call. Step 4: Layout and render the UI The final step in the process is to cause the document to layout and render the UI content model that it has been given. It is expected that with few changes, this process will look identical to the normal processes involved in laying out and rendering the main HTML content model. Note that this process does not assume
a unique layout manager. Ultimately, a table will wrap the UI elements
in the UI content model, and our existing layout processes should suffice.
Integrating the XUI schema with Raptor requires only a minimum set of changes. This set includes changes to the parse system, the DTD, the content sink, the content model, the document and finally the DOM. Each of these is described below. Parser Changes The first change required to integrate XUI with Raptor occurs at the parser level. At a minimum, we must ensure that the existing HTML token set is updated to handle any XML style extensions required to conveniently express the XUI schema. At this time, no such extensions are expected. DTD Changes Our existing NavDTD needs to be subclassed to create a XUI-DTD. This DTD will cache all incoming tokens. Once fully tokenized, the XUI-DTD will iterate its token cache, and transform the elements into a set of well-formed HTML elements. Next the sink is opened with a call to OpenUserInterface(...), and then the transformed HTML elements are written. The last step will be to call the corresponding sink method, CloseUserInterface(...). ContentSink Changes For the sake of clarity and to properly document the relationship between the sink and the DTD, it is recommended that the contentsink API be expanded to include a new pair of interfaces: nsresult OpenUserInterface(...); nsresult CloseUserInterface(...);Note that the sink will use OpenUserInterface(...) call to denote that the UI content-model should be updated and not the usual document content model. This state is terminated upon receipt of the CloseUserInterface(...) call. Document Changes This approach assumes that the construction and maintenance of a separate UI content model. When laying out the UI, the document will iterate this model rather than the usual document content model. Note however that the UI content model will undoubtedly contain an area into which the document content model is laid out. Note: An important step which I'm hand waving here is the binding of resources to UI elements defined in the XUI schema. I've not forgotten it, but it seems like a known art, and therefore I'm handwaving. You've been warned. DOM Changes While it is not strictly necessary,
it would be advantagous to reflect the UI content model through the DOM.
This would permit content developers to manipulate the UI in a programatic
manner, much the same as they manipulate the main content model today.
The following examples are intended
to illustrate the manner in which a UI can be described using the XUI/XML
application schema. These examples are intentionally simplistic, but should
provide a clear understanding the overall intention of this system. Clearly
these examples do not provide evidence at this time that XUI is presently
sufficient to describe an entire UI such as the Navigator.
<?xml version="xml 1.0"?> <document type="xui:app"> <!-- describe the main menu --> <menubar align=top dockable=true> <menu type=pulldown label="_File" statusmsg="show in statusbar"> <menuitem label="_xxx" accelerator="^X"/> <menuitem label="_yyy" accelerator="^Y"/> </menu> <menu type=pulldown label="_Edit" statusmsg="show in statusbar"> <menuitem label="_xxx" accelerator="^X"/> <menuitem label="_yyy" accelerator="^Y"/> </menu> <menu type=pulldown label="_View" statusmsg="show in statusbar"> <menuitem label="_xxx" accelerator="^X"/> <menuitem label="_yyy" accelerator="^Y"/> </menu> <menu type=pulldown label="_Go" statusmsg="show in statusbar"> <menuitem label="_xxx" accelerator="^X"/> <menuitem label="_yyy" accelerator="^Y"/> </menu> <menu type=pulldown label="_Communicator" statusmsg="show in statusbar"> <menuitem label="_xxx" accelerator="^X"/> <menuitem label="_yyy" accelerator="^Y"/> </menu> <menu type=pulldown label="_Help" statusmsg="show in statusbar"> <menuitem label="_xxx" accelerator="^X"/> <menuitem label="_yyy" accelerator="^Y"/> </menu> </menubar> <!-- describe the main toolbar --> <toolbar label="main" align=top> <button type=push label="back"> <img src="backimg"/> <tooltip label="backtip"/> <menu type=popup> <button label=xxx/> <button label=yyy/> </menu> </button> <button type=push label="forward"> <img src="forwardimg"/> <tooltip label="forwardtip"/> <menu type=popup> <button label=xxx/> <button label=yyy/> </menu> </button> <!-- more toolbar buttons go here... --> </toolbar> <!-- describe the location bar --> <toolbar label="location" align=top> </toolbar align=top> <!-- describe the client area --> <clientarea label="clientarea"/> <!-- describe the status bar --> <statusbar label="statusbar" align=bottom> <text label="area1" value="your message1" border=1/> <text label="area2" value="your message2" border=1/> <text label="area3" value="your message3" border=1/> <toolbar label="mini"> <button type=push label="navigator"> <img src="nav"/> <tooltip label="xxx"/> </button> <button type=push label="inbox"> <img src="xxx"/> <tooltip label="xxx"/> </button> <button type=push label="newsgroup"> <img src="xxx"/> <tooltip label="xxx"/> </button> <button type=push label="addrbook"> <img src="xxx"/> <tooltip label="xxx"/> </button> <button type=push label="composer"> <img src="xxx"/> <tooltip label="xxx"/> </button> </toolbar> </statusbar> </document>
Confidential -- Copyright 1998, Netscape Communications
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1998 The Mozilla Organization. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||