OpenWGA 7.5 - OpenWGA Concepts and Features

Design and development » Design configuration

Tab "Design Configuration"

This tab contains the basic configuration of the OpenWGA design.


Section "General"

The readonly setting Directory shows the path of the currently opened OpenWGA design directory.
This is followed by three settings which identify some TMLScript scripts that are to be run at special events. All three may address individual TMLScript module files contained in the design directory:

  • The "Initialisation script" is a script that is only called when the design gets connected to an empty OpenWGA Content Store. That is the case when a content stores does contain no Website areas, content types or language definitions. It is one alternative for initializing a new OpenWGA content store which also can be done using schema definitions or an initial content store dump
  • The "Connection script" is a script that is called each time an OpenWGA application using this design gets connected to an OpenWGA server
  • The "Disconnection script" (only available to designs at least developed for OpenWGA 5.1) is a script that is called each time an OpenWGA application using this design gets disconnected from an OpenWGA server (assuming that the OpenWGA server is given the opportunity to actively close the application, which is of course not the case on a hard system shutdown)

All these scripts are executed under master session rights as "non-web" scripts, i.e. they have no access to the WebTML environment. The usable TMLScript functionality matches the one documented for "TMLScript Jobs". It is run under a "dummy context" of the connected application.

Note that all scripts are executed before/after the OpenWGA application gets online. The WebTML context of the application database itself therefor is only only available as default context of the script. Fetching the regarded application by other functionalities, for example via database key, will fail here.

This is followed by two settings which are used to initialize the access control list (ACL) of a connected OpenWGA content store if it is empty (i.e. there are no entries yet). Both may contain an access level for the individual entry to create or "Do not set" to not create this ACL entry.

  • The field "Default access level" creates an entry for name "*" in the ACL, which matches all users of the application without a better matching ACL entry. 
  • The field "Anonymous access level" creates an entry "anonymous" in the ACL, which matches all non-authenticated users.

The setting here called "Version compliance" configures the compliance of this design with OpenWGA versions. The compliance let the OpenWGA server emulate the behaviour of the specified OpenWGA version for your design, no matter what the actual OpenWGA server version is. That way newer OpenWGA versions can provide improved behavious for newer designs while still keeping the old behaviour for old designs and therefor ensuring their functionality. When developing a new design you should always choose the compliance of the current OpenWGA server version that you intend to use for your design.

This setting is followed by another setting "Minimum WGA version", whose effect may not be completely distinguishable from the compliance at first sight. But instead of emulating behaviours this setting directly determines a minimum OpenWGA server version that this design needs to work correctly and therefor influences the features that are available for your design. You can set it to a higher version than the compliance to a) ensure the behaviour for which your design was originally developed but b) allow usage of features from newer OpenWGA versions to which you may have updated your OpenWGA live server. However, this field is disabled if the compliance is lower than "7.0", as older OpenWGA servers do not respect this setting. In that case either the version compliance or the optional plugin configuration determine the minimum WGA version, which is shown in this field for reference.

For plugins this field obsoletes the same "Minimum WGA version" field on the plugin configuration, which is disabled in situations where this new field is in enabled.

The following table shows the implications of the available version compliances and minimun WGA versions in detail. Every documented version includes the implications of earlier versions:

OpenWGA Version As compliance As minimum version
  • Emulates old WGA 3 behaviours when retrieving nonexistent items and other fields, which frequently returned empty strings
  • New behaviour for retrieving nonexistent items, consistently returning null for single values and empty lists for multiple ones
  • Apps using this design need a content store of at least version 4.1 (optimized file handling)
  • Design shortcuts are available in design configuration
5.0 - 5.1
  • Apps using this design need a content store of version 5
  • HDB API is available on demand, therefor the HDB interface flag in design configuration is implicitly enabled
  • A disconnection script can be defined in design configuration
  • The Java classpath of a libraries can be marked "static" in design configuration, preventing it from being discarded and rebuilt on reconnects
5.2 - 5.5  
  • Design schema is available in design configuration
  • New handling of files on WebTML forms: Uploaded files survive further POST requests, document file attachments and form files are synchronized
  • New portlet context behaviour: portlet context is cleared on portlet mode change
  • URL parameters are always kept on WebTML action calls
  • URL parameters given to client-side JavaScript functions WGA.action() and WGA.ajax.action() are automatically encoded
6.2 - 6.3
  • Uses OpenWGA 6.2 WebTML portlet handling (i.e. "transient portlets") by default
  • Parameters of portlet events can also be of type number/date/boolean, are also transferred to clientside JavaScript in that type
  • WebTML encoder "html" also encodes single quotes
  • WebTML label parameters are also encoded in WebTML default encoding
  • The field "Minimum WGA version" is enabled on the design configuration, allowing to determine the OpenWGA server version needed to use this design separately from the compliance. The same field on the plugin configuration is obsolete and disabled.
  • Encoder mappings, element mappings, media key mappings, job definitions and design shortcuts are additionally available on the design configuration of customization directories
  • The flag "Does not need a content store" is available on plugin configuration

Section "Libraries"

This section allows an OpenWGA design to add Java JAR libraries to the OpenWGA classpath. The Java classes provided here are usable in may ways, for example via TMLScript, as OpenWGA scheduler jobs, WebTML elements or encoders etc.

To add a JAR library here just click the "add..." button. The library will be copied to the system file container of the design under subfolder "/files/system". Vice versa you can click "remove..." to remove any JAR library already added.

The checkbox "Prevent reloading of java libraries", which is off by default, may be checked if these libraries, or rather the classloader loading them, may not be automatically rebuilt while OpenWGA server is running. The OpenWGA classpath is rebuilt on various occasions, for example when an OpenWGA plugin is added or an OpenWGA application reconnected. This may pose problems to some classes that store state in a static way as this will result in re-initialisation of that state. Check this setting to let OpenWGA keep the class loader for your libraries while OpenWGA classpath is rebuilt, so this state is also kept. A drawback of this setting is that your libraries will not get updated for an existing OpenWGA server runtime, even if you add, replace or remove JARs.

Section "Publishing"

This section controls the publishing behaviour of OpenWGA for applications with this design. They therefor complement or set defaults for the "Publishing settings" of an OpenWGA application. Most of them can be overriden in the publishing configuration of the individual application if neccessary.

This section is introduced with two settings for special pages for the application design. 

  • The Home Page is a setting which defines a page on the application that should be shown when the application is called without specifying a special resource. 
  • The Login Page is a setting specifying a special page for logging in users with it. It is used when the user calls a WebTML-generated Login-URL (type="login").  This will only work if your application is open to anonymous access since the login page must reside in the applications design itself when set here. There are other possibilities when the login page is set in administration.

    In both cases you should specifiy a partial URL that must not begin with a slash. It is used to extend the base URL to the application that uses the design. For example imagine a home page setting of:


    If an application using the design is called via the following URL:

    Then the setting will be interpreted as:

    This effectively will call a document named "home" in the application. By adapting the partial URL to your needs you could also address an individual WebTML module.

    The setting Default WebTML Output Encoding sets a default WebTML encoder for all WebTML tags of this design that are vulnerable for security threats based on "Cross site scripting". It therefor offers the ability to automatically prevent these kind of attacks in most cases, for example by choosing encoder "html" which will not let these tags put out any functional HTML tag. The affected functionalities are:

    • Output of <tml:item>
    • Output of <tml:input> in mode "view"
    • Output of <tml:urlparam>
    • Parameters on WebTML labels

    Individual tags can however override this setting with an explicit attribute "encode". As the WebTML code of an application must be created with this setting in mind - since unwanted encoding may break functionalities - the default setting here is "none" which does no automatic encoding.

    The setting "Design encoding" declares the text encoding that is to be used by text-based files of the design directory. OpenWGA will read those files using this encoding. We recommend using "UTF-8" wherever possible. The link "Enforce design encoding" below it will parse all textual resources and mark all errors according to the currently chosen encoding.

    This section is followed by some flag checkboxes triggering special application behaviour:

    • The flag Multi Language Content controls if OpenWGA should treat contents in applications of this design as being "language dependent" and therefor try to serve only languages that the user accepts (regarding his browser configuration) . It is enabled by default. Disabling it will keep OpenWGA from interpreting the language of content documents in any way. This only makes sense if there only is one language in the applications database which then will always be served, no matter what language the user may accept. This is typical for data-driven applications where the data is not available in multiple languages.
    • The flag Uses HDB interface may be checked if the design uses the "Hierarchical Database API" internally. It is obsolete for applications that target OpenWGA 5.0 or higher since in these versions the HDB interface will automatically be initialized on its first usage.
    • The flag Only accessible with administrative login marks an application that should only be available to logged in OpenWGA administrators. OpenWGA will prevent any HTTP access to it when the user is not logged in as admin and redirect calls to the administrative login page. 

    At the end there is the setting browsing security. It controls the ways that browser users of the design are able to access individual content in your application. You should consider changing this setting from the default value "Normal access" to a more restrictive one if you cannot rely on the built-in OpenWGA features for content access alone.

    OpenWGA automatically ensures that users cannot perform operations or see data in a way that is not permitted by its built-in Authorisation features, which are ACL and document level authorisation fields. Your application design does not need to enforce anything that is guaranteed by these features, nor is any special browsing security setting neccessary to enforce this. However your design may choose to enforce additional security restrictions that further reduce the users access beyond what is allowed by built-in authorisation, for example make some documents invisible or reduce the ways that docs may be modified. In that case it may be neccessary to adapt browsing security so that other OpenWGA features do not act as security holes to your designs restrictions:

    • The setting "No authoring" will prevent applications that use your design from being opened in authoring applications like OpenWGA content manager. This will keep author/editor users from modifying the content documents there in ways that are not intended by your design. So the functionalities offered by your design remain the only ways of modifying content data.
    • The setting "No authoring and content addressing" builds upon the previous setting by also disabling the possibility to choose the content to display via URL. This will keep all users from seeing content documents that they technically are allowed to see but your design does not want to show them. Note however that this will completely disable the usage of all URLs pointing to content and the only way to access your application will be by addressing layouts directly, i.e. use "contextless" requests explicitly addressing WebTML modules.