![]() |
![]() |
||||||
|
|||||||
eNode UI Markup Language is very simple, but behind this simplicity lurks enormous power. That power is derived in large part from the rich collection of element types defined by the language, and from the limitless number of ways in which elements of these types can be combined to describe complex object compositions. We begin the tutorial by introducing the frame element type that represents a top-level window, and the label element type which represents a static label consisting of a single line of text, or an icon, or both. Frames
A frame is a top-level window which contains
other user interface controls and views. The views and controls inside a frame
are visible only if the frame itself is visible.
A frame’s location and size may be set explicitly, failing which, it is
packed so that it is just large enough for its
contents to fit snugly inside it. In either case, a frame is
resizable under user control, unless declared
otherwise.
Namespaces If you are familiar with HTML, you probably know that the frame element type means something completely different in HTML than it does here. Even though the name is the same in both cases, the semantics are different — The semantics of an element type are defined by the namespace that the element type belongs to. In order to avoid confusion, you must clearly indicate in your XML documents the namespace that an element belongs to. XML documents processed by eNode Object Realizer must conform to the eNode schema, which defines the vocabulary and grammar of eNode UI Markup Language. Unless constrained by a schema, XML documents may contain elements of any type, and from any namespace. Although the eNode schema may allow elements types from other namespaces in future, eNode Object Realizer currently recognizes only element types from the eNode namespace. A namespace itself is identified by a namespace identifier. The namespace identifier for the eNode namespace is http://www.enode.com/xalt. Our first example displays a static text label in a window. To accomplish this, we must first describe what we want in an XML document. The root element of an eNode document must be a resource element from the eNode namespace. A resource element contains a resource description. In the following example, the resource description is comprised of a frame element, which, in turn, contains a label element — The resource element itself is not considered part of the resource description. Copy the code from the above text area, paste it in eNode Sandbox, and “Make” it. The result should be similar to the following: Note: The term resource description, as used here, has nothing to do with the W3C activity called Resource Description Framework (RDF). RDF is a framework for describing and exchanging metadata which are the building blocks for the Semantic Web. Document Structure eNode documents must, at a minimum, meet the requirements of well-formed XML documents. A document must start with the mandatory xml declaration identifying at least the version of the XML specification that the document conforms to. At present there is only one version, identified as version="1.0". An optional encoding parameter identifies the character-encoding scheme used in the document. If this information is not present, then, by default, UTF-8 encoding is assumed. The xml declaration is followed by a single resource element, which is the root element in an eNode document. The resource element typically contains a presentation element, but may contain other elements. To accommodate elements from different namespaces, eNode documents must identify the namespace that each element belongs to. This can be done either by adding a namespace prefix to each element, or by defining a document-wide default namespace. A default namespace definition may be preferable to per-element prefixes because the latter can cause a lot of clutter. You can establish a document-wide default namespace through the xmlns attribute of the root element. Elements that do not carry an explicit namespace prefix are deemed to belong to the default namespace. In the above example, this means that even though the frame and label elements do not have any namespace prefix, they belong to the eNode namespace because of the xmlns attribute of the resource element. Element Realization eNode Object Realizer can realize objects from resource descriptions. By default, the realized form of a frame element is an instance of javax.swing.JFrame, and that of a label element is an instance of javax.swing.JLabel. eNode UI Markup Language defines the default mapping between an element type and the class used to realize an element of that type. It is easy to override this default mapping and substitute a different class, perhaps one that is user-defined, to realize an element. This can be done directly in the markup, on a per-element basis. Element Attributes We have already mentioned that eNode UI Markup Language defines a large number of element types. To capture the full richness of objects represented by these element types, the language also defines a large number of attributes for these element types. Even seemingly simple element types such as label can support dozens of attributes. Attributes for an element may be specified in any order without changing the collective effect of all attributes for that element. The following example shows one way to specify the foreground and background color attributes for the label element. The order in which the attributes are specified can be changed without changing their net effect on the realized label. Make this object in eNode Sandbox. The result should be similar to the following: ![]() Colors The foreground and background colors of all presentation component can be set through the foreground and background attributes, respectively. The foreground color is painted without regard to whether the component is opaque or transparent, but the background color is painted only if the component is opaque. By default, labels are transparent. Setting opaque="true" ensures that a label’s background color, if any, is properly rendered. For a complete list of supported color names, see Color. In addition to specifying colors by name, you may specify colors using numeric RGB values. |
|||||||
|
Copyright © 2002 eNode, Inc. All Rights Reserved. |