OpenWGA 7.9 - OpenWGA Concepts and Features

Design and development » Design configuration

Tab "Plugin Configuration"

This tab holds all neccessary setting to distribute an OpenWGA design as OpenWGA plugin. They only get effective if the design is really installed as an OpenWGA plugin, not if it is merely used as a file system based design for applications.

pluginconfig.png

Section "Registration" contains the basic identifying data of this plugin:

  • Unique Name: A unique name for the plugin. Plugin unique names have the same format as fully qualified Java classes and should be preceded with domain information.
  • Version: The version number of the plugin, divided up into a main version string of format "0.0.0" and a numeric build number
  • Minimum WGA Version: The minimum OpenWGA version neccessary to install this plugin. For designs with a version compliance of 7.0 or higher this field is disabled. Instead the equally named value from tab "Design configuration" is in effect and only shown here.
  • Minimum Java Version: The minimum Java version that OpenWGA is to run on to install this plugin

Section Dependencies declares dependencies to other OpenWGA plugins that need to be installed for this plugin to work. OpenWGA will prevent activation of this plugin if a dependency plugin is missing or has a too low version. It also will automatically connect dependency plugins before their dependent plugins. Manage this list with its "add" and "remove" buttons. Each entry needs the unique name of the dependency plugin and the minimum version of it (the main version string without build number).

Section Exporting offers some actions to distribute the plugin. With "Export WGA Plugin to remote server" you can directly upload and install the current plugin state to some registered OpenWGA remote server. With "Export WGA Plugin to local file system" you can create a standard OpenWGA plugin file which then can be distributed manually.

Section Information and Functionality further describes the plugin and sets some special purposes:

  • Title: A descriptive title of the plugin
  • Vendor: Name of the plugin vendor
  • Vendor Homepage: Homepage of the vendor on the INet
  • Description: A description of the purpose and contents of this plugin
  • Plugin Homepage: A partial URL leading to a "homepage" of the plugin. It should be equally formated like publishing setting "Home Page" (see Tab "Design Configuration"). In plugin administration there is a link to the homepage of each plugin that declares one, which mostly is used to direct to a settings dialog, show documentation etc. Only effective if usage includes "Published WGA Content Store".
  • Authentication source: This setting can specify an authentication source for accessing the plugin itself (not for applications relying on this plugin in any way). Only effective if usage includes "Published WGA Content Store".
    • none: No authentication
    • Default Domain: The authentication configured for the domain "default" of the individual OpenWGA server
    • Myself: The plugin itself as an authentication content store. Only available if configured usages includes "Authentication source"
    • Plugin-Name: A dependency plugin as authentication content store. All dependency plugins are shown here with their names.
  • Personalisation mode: The personalisation mode which should be used for the plugin itself (not for applications relying on this plugin in any way). Only effective if usage includes "Published WGA Content Store".
  • Usage: A choice of special usages for this plugin which OpenWGA server will provide and related options
    • Design Provider: The design of this plugin may be used by OpenWGA applications
    • Authentication Source: The plugin is an authentication content store.
    • Published application: The plugin itself will get published as OpenWGA application.
    • Does not need a content store: The plugin does not need persistent storage in its plugin content store, neither regarding content nor user profiles. It will not be possible to store anything in this plugins content store. This speeds up the plugin connect/disconnect process. Checking this will implicitly set the personalisation mode to "Session based".
    • Clear plugin content store on update: Enable this if on each update of the plugin the plugin content store should be completely reset. This is handy if the plugin database contains documentation about the plugin which should be updated on each new plugin version.
    • Do not execute init/connect functionalities on plugin itself: Checking this will prevent the plugin itself from running initializing functionalities. This is often desired when the plugin is a design provider and the initializing functionalities should only run on applications that use this design, but not on the design plugin itself. The prevented functionalities are:
      • Init/Connect/Disconnect script
      • Importing initial content store dumps
      • Enforcing schema
      • Registering jobs from design configuration