XApperator
lightweight, manouverable and quickly deployed
lightweight, manouverable and quickly deployed
There's no configuration 'system' as such in XApp, each instance has a standard and simple config.xml file which specifies the format of the actual application data files and the operations that users are permitted to perform on them.
Following is an abbreviated overview of the structure of a typical config.xml file, each of its top-level elements will be discussed in detail:
Note: A DTD is provided with the XApp distribution to validate the config.xml file if you're using a validating editor. If you dont use a validating editor, a command-line validating perl script ValidateConfig.pl is included. Config.xml file can be renamed as long as your controller.cgi script is pointed at the new name using its XApp object configFile property.
The <meta> element is used to store meta-data for the application, its mostly a reference for developers and only the <title> is actually used within XApp itself.
The <titles> element is optional and contains a child for every UI prompt or error that must be displayed by XApp. If you do not include this tag the default XApperator system prompts will be used. Note in the following the developer has provided alternative copies of each title for German (approx translation courtesy of babelfish ;) through use of the xml:lang attribute
The <messages> element and children serve a similar purpose to the <titles> elements but are used to show more detail concerning a given UI event or error. This element is also optional and will default to the standard XApperator messages if not included. Alternative language copies of messages are excluded in the following example but can be used in the same way as multi lingual titles
The <actions> element and children define what user actions are allowed in this instance of XApperator. The purpose of each should be obvious and each is checked by the XSLT that generates the UI to determine whether to show or mask the buttons associated with that action.
In case a user tries hacking the CGI paramaters to invoke an action not exposed through the UI, XApp will check these config settings and block those actions if not specifically enabled. The 'publish' action is the only element with children and each child <transform> element specifies where content should be rendered to and which XSLT they should be pushed through if publishing is enabled.
The <schema> element contains definitions of fields within each record of the data file for the application. This is the glue between the data files and the application. The contents of the fields are interpreted by the app and reflected in the user interface. Check out the Schema Quickref page.
Authored using: XApperator
