This example is a dialog window in which a form containing different types of fields (text, choice, link, date, number and file) is put.
This example is a main window in which a tree, a map and a list are placed. These three elements are placed by using splitter panels in order to allow to modify the place that they occupy.
<xml version="1.0" encoding="ISO-8859-1"?> <!ELEMENT EXAMPLE (TEXT)> <!ELEMENT TEXT EMPTY> <!ATTLIST TEXT label CDATA #IMPLIED> |
<xml version="1.0" encoding="ISO-8859-1"?> <EXAMPLE> <TEXT label="Label of example">This is an example of XML</TEXT> <EXAMPLE> |
The names of the attributes are in lowercase except the first letter of the second word, if these names are made up of two words.
When the value of an attribute is alphanumeric, this value is declared as being of CDATA type.
When the value of an attribute is numeric, this value is declared as being of NMTOKEN type.
When the value of an attribute is Boolean, the two possible values are true and false, in lowercase.
When the value of an attribute belongs to a discrete list of values, the different possible values are in uppercase (with an underscore if they are made up of several words).
The attributes of ID type are named id.
When an attribute represents the displayable text of a component, this attribute is called label.
The second solution is more flexible because it allows to manage the multilingualism.
Actually, all the displayable strings of the application can be managed through a key representing an entry in a dictionary that depends on the language (generic dictionary: strings_
The search in this dictionaries is made as follows: the search is first performed in the specific files of the application in the following order:
In an XML document of view description, you will rather use these keys than the values that directly depend on a given language, when it is possible.
The syntax of the dictionaries of image type is the following:
Two syntaxes are possible for these dictionaries:
The syntax for these dictionaries is the following:
The syntax for this dictionary is the following:
The syntax is the following:
The identifier of an object is specified by an attribute named id, which can be required or implicit.
In many objects of the descriptive model of the views, you will find an attribute named controller. This attribute corresponds to the reference of the entity that owns the functioning mechanisms of the object. This attribute is filled in automatically by the application at the creation time of the views.
Then, the search browses the generic strings:
Finally, if the key is not found, it is kept. The syntax of the dictionaries is the following:
STRING_KEY=a string
In order to distinguish them well, the names of the keys are in uppercase. If a key is made up of several words, these are separated by an underscore (_).
Nevertheless, in the following examples all the displayable strings are given literally to make the reading of these examples easer.
<ICON label ="A string"/>
<ICON label ="STRING_KEY"/>
Messages management
The management of the messages also depends on the language and the mechanism is the same as for the strings. To do that, dictionaries are available; they are under the form: messages_Images management
The images are managed in two dictionaries. The first is specific to the application (images_app.properties) and the second is generic (images.properties). The management of the images also depends on the language.
IMAGE_KEY=image.gif
In the XML files of view description, it is possible to specify (force) the wished size of the image. The size must be indicated under the form (width,height). The images are searched for in the user's CLASSPATH at the startup of the application.
<ICON label="Button label" image="consult.gif"/>
<ICON label="Button label" image="LY_ACTION_CONSULT"/>
<ICON label="Button label" image="consult.gif (20,20)"/>
<ICON label="Button label" image="LY_ACTION_CONSULT (20,20)"/>
Colors management
The colors are managed in two dictionaries. The first is specific to the application (colors_app.properties) and the second is generic (colors.properties). The management of the colors also depends on the language.
The references for the color codes are defined in the color_code.properties dictionary by using the RGB syntax.
COLOR_KEY=255 240 245
COLOR_KEY=LavenderBlush
Fonts management
The fonts are managed in two dictionaries. The first is specific to the application (fonts_app.properties) and the second is generic (fonts.properties). The management of the fonts also depends on the language.
FONT_KEY=fontname-fontweigth-fontsize
FONT_KEY_BOLD=arial-bold-12
FONT_KEY_BOLD_ITALIC=arial-bolditalic-12
FONT_KEY_ITALIC=arial-italic-12
FONT_KEY=arial-12
Files management
The files are managed in a dictionary (files.properties). The file management also depends on the language.
FILE_KEY=file path
FILE_KEY=file.doc
Generic resources management
The generic resources are resources that do not fall into any of the categories above. For example, they can specify the functioning mode of an application or the generic appearance of a presentation. These resources are managed in two dictionaries. The first is specific to the application (resources_app.properties) and the second is generic (resources.properties). The management of the resources also depends on the language.
KEY=value
LY_WRITE_TOOL_LABEL=false
Using object references
Some objects built in the descriptive model of the views must be identified by a unique identifier within a same view. A view is a window that is shown in an application. It corresponds to displaying an element of FRAME or DIALOG type.
Note : OBJECT is a fictive element that is given as an example of the met syntax.
<ATTLIST OBJECT
id ID #REQUIRED
... >
This object identifier enables other objects of the model (form, node of a map...) to refer to the object, but it is principally used to retrieve easily the object by programming.