Create an application configuration file

An application configuration file provides the Genero Application Server with the information needed to run an application. It becomes available for use as soon as it is created and added to a recognized group directory.

To add an application, create an application configuration file and save it in $FGLASDIR/app. The name of the file should match the name of the application and have an xcf suffix. For example, if the application name was "app1", create a configuration file named app1.xcf.

Note: Before you add your application configuration, it is assumed that you have validated your installation.

The APPLICATION element defines an application environment. Within this element, you can define local resources, change the execution environment, the timeout settings and the picture and output settings. You can refer to previously defined components by using the tag attribute Using.

Syntax

<APPLICATION Id="appId" [ Abstract="{ TRUE | FALSE }" ] [ Parent="pAppId" ] >
[ resource ] [...]
[ <EXECUTION [ Using=" exCompId " ] > execution </EXECUTION> ] 
[ <OUTPUT Rule="UseGWC">
    <MAP Id="DUA_GWC" Allowed=" { TRUE | FALSE } " >
        [ <TIMEOUT [ Using=" timeCompId " ] > timeout </TIMEOUT> ] 
        [ <PICTURE [ Using=" picCompId " ] > picture </PICTURE> ] 
        [ <THEME [ Using=" themeCompId " ] > theme </THEME> ] 
    </MAP>
  </OUTPUT> ] 
</APPLICATION>

appId is the application identifier.
pAppId is the parent application identifier.
An abstract application is used to share common configuration between multiple child applications. An abstract application can't be instantiated.
resource is a local RESOURCE definition.
exCompId, picCompId, timeCompId and themeCompId are components identifiers.
The content of execution, timeout, picture and theme is the same as the content of their respective components.

Example 1

The simplest application configuration file only needs to specify a parent application and the path to the compiled application files. In this example, the application inherits the configuration settings of the parent application. This XML would be saved in a file named appname.xcf, where appname is the name of the application.

The following XML defines the Edit application in an external application configuration file Edit.xcf.

<APPLICATION Parent="defaultgwc">
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="http://www.4js.com/ns/gas/2.50/cfextwa.xsd">
  <EXECUTION>
    <PATH>$(res.path.fgldir.demo)/Widgets</PATH>
  </EXECUTION>
</APPLICATION>

Details about this example

The name of the application is the name of the .xcf file. The Idattribute of <APPLICATION> tag is omitted; even if included, its value is not read. Instead, the GAS uses the name of the configuration file to identify the application.
The application configuration file is re-read at each application launch. There is no need to restart GAS after modifying an external configuration file.
The directory where the GAS searches for the external application configuration file is defined in as.xcf by the tag <GROUP Id="_default">directory</GROUP>. The default after installation is $FGLASDIR/app.
The Parent application is defined as defaultgwc. A parent application is an abstract application that provides default component configurations. This means that the application will inherit the configuration settings defined for the default GWC (defaultgwc) application, which is an abstract application defined in the GAS configuration file.
The path to the application executables is defined by the PATH component.
No MODULE element is needed when the external configuration file shares the same name as the application. When there is no defining <MODULE> tag in the application configuration, the module taken by default is the name of the application.

Example 1 limitations

An external application cannot be an Abstract application.
An external application can only inherit from an internal application.

Example 2

While an application inherits its base configuration from the parent application, additional configuration elements can be added and existing configuration elements can be overwritten. This next example is of a hypothetical external application configuration file, tutorialStep1.xcf.

<APPLICATION Parent="demo-tut-abstract">
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="http://www.4js.com/ns/gas/2.11/cfextwa.xsd">
  <!-- Define a resource to the template HTML file -->
  <RESOURCE Id="res.template.tutorial" 
    Source="INTERNAL">$(res.path.demo.dem-tut)/web/tutorial/tutorialStep1.html
  </RESOURCE>
  <EXECUTION>
    <PATH>$(res.path.demo.dem-tut)/src</PATH>
    <MODULE>tutStep1.42r</MODULE>
  </EXECUTION>
  <!-- Override default rendering template -->
  <OUTPUT>
    <MAP Id="DUA_HTML5">
      <THEME>
        <TEMPLATE Id="_default">$(res.template.tutorial)</TEMPLATE>
      </THEME> 
    </MAP>
  </OUTPUT> 
</APPLICATION>

Details about this example

The Parent attribute of the APPLICATION element defines the parent application as "demo-tut-abstract". Unless a value is overwritten locally in the application configuration, the child application inherits the configuration elements defined by the parent application.
The RESOURCE element defines a local resource. This resource maps to a template file.
The PATH and MODULE elements provide the path and file name of the program executable. It is common to exclude the MODULE element when the executable name matches the application name as provided in the URL. In this example, if the external application configuration file had been named "tutStep1.xcf", then the MODULE element specifying the program executable as "tutStep1.42r" could have been excluded.
The Id attribute of the MAP element defines the output map as "DUA_HTML5".
The TEMPLATE element overrides the default template (Id="_default") with the template defined by the "$(res.template.tutorial)" resource previously defined by the RESOURCE element.