As a web application directly
As we described earlier an installed plugin is actually a special form of an installed web application. Therefor it is of course possible to also use the plugin as web application, meaning: To access it directly via browser, work with it, store data in its content store. A plugin design striving for this usage case may just get programmed like any regular web application.
Some default plugins of OpenWGA have this usage type, like the OpenWGA content manager and the OpenWGA admin client.
Some configuration options in design configuration that may be set for that usage case:
- On tab Plugin Configuration:
- Check Usage checkbox "Published WGA Content Store". Without it your plugin will not be accessible as browser.
- Optionally choose an "Authentication source" for your plugin, if you want the browser users to login to your plugin application
- Optionally choose the "Personalisation mode" for the plugin application if you use personalisation/portlet functionalities
- You may also specify a "Plugin homepage", which is any partial URL to the plugin application, beginning after the database key part. If that is set then the plugin title in OpenWGA admin client, menu "Plugins / Plugin Management" will be a link leading to that URL.
- On tab Design Configuration
- Check if you need to set "Default access level" and/or "Anonymous access level" for your users to be able to actually access the plugin app without modifying its ACL
- Generally check all other settings which make sense for your web application, as all of them may apply.
Do not confuse this usage type with the usage as a design provider, described in the next chapter. The difference is, that a design provider gives its design to "real" OpenWGA web applications while in this usage case here the plugin itself is the web application.
As design provider for web applications
Plugins can be used just like regular design directories to provide a design for any OpenWGA web application. These plugins are called "design providers". If you have any design directory which you use as design for an OpenWGA web application you can also distribute it as design provider plugin, just by creating a plugin configuration in its design configuration, exporting it as plugin file and installing it on those servers that are about to use it.
When creating a new web application in OpenWGA admin client you use a design provider plugin by specifying "Plugin" as design source. Then a list of all installed plugins that are marked as being design providers is shown, from which one can be selected:
All predefined application designs for OpenWGA, like wiki, blog or the Basic Website Kit are distributed as design provider plugins. This is the preferred way to distribute OpenWGA designs for a larger audience.
What happens when an application inherits its design from a plugin is not that different from using a design directory. Plugin distributions are actually regular OpenWGA designs, just in a different form. Using a plugin for an application design is the same as using the design directory, from which the plugin was built, directly.
Settings in design configuration to observe when creating a design provider plugin:
- On Tab "Plugin Configuration"
- Under "Usage" check the checkbox "Design Provider"
- In most cases you also want to check "Do not execute init/connect functionalities on plugin itself", so the installed plugin app itself does execute what actually is meant for the design consumer. This only makes sense if you want some kind of "mixed usage", like described below.
- If your plugin design is a customization of a base plugin (like the Basic Website Kit, for example) then you should include a dependency to your base plugin in the configuration. Open the section Dependencies and add an entry to the dependency table there, containing the unique name of your base plugin and its version.
- On Tab "Design Configuration"
- Ensure that both, Default and Anonymous Access level are set to "reader". In order to use a plugin as design provider it must be "readable" for everyone.
- Choose all other settings in the design configuration, having in mind that these settings will be enforced on all design consumer apps
As authentication source
Installed plugins may be used as authentication sources. This is actually the same as using a Content store for authentication, only that this time it is no complete web app holding the user/group data but a plugin app and its content store. Authentication data like user and group definition documents are stored in the content store of the plugin and read from there to validate authentication requests.
Generally you need to prepare your plugin for being an authentication source just like a content store. See Structure of an authentication content store for details.
As a special step you need to declare the root documents for users and groups and all other settings via Integrated configuration. When using a plugin as authentication source there is no way to configure this settings, so the plugin itself needs to know its necessary settings.
Ensure the following settings in design configuration:
- In Tab "Plugin Configuration"
- Under "Usage" check the checkbox "Authentication Source"
- If your plugin has mixed usage and should also be available as web application (for example to provide managing access to defined users and groups) then you could now also change the "Authentication source" to "Myself", so the plugin web application uses itself as authentication source for web access.
As provider of any resource
Instead of using a plugin like a regular app or in one of the predefined usage scenarios plugins also may choose to only provide any resource to the rest of the system. This may be WebTML/Script modules, files in file containers, a TMLScript global or any of the resources described in Extending OpenWGA.
Mostly these are resources used for programming other OpenWGA designs. They provide a special functionality that is often used in OpenWGA development, like the implementation of a frequently used task or a UI interface library. Many default plugins of OpenWGA fall into this category, like the "WGA Application Framework", the "Application UI Interface Library".
At other times these plugins are extending the core capabilities of OpenWGA, like giving access to additional data sources, allowing the usage of additional authentication backends or add additional services. The "OpenWGA Enterprise Plugin" is such a plugin which adds the functionality of the OpenWGA Enterprise Edition, but also the "OpenWGA Web Services XFire Server", which adds the SOAP web service to the OpenWGA runtime..
Plugins may mixup any of the usages described above. There is no need to restrict to only one usage.
For example: A plugin for use as an authentication source might also be published as a web application, which allows the management of the user and group documents inside the plugin content store. Or: A design provider plugin may additionally register additional resources, like a new WebTML encoder which is used inside its design.
Another interesting example is the "OpenWGA Wiki Design" plugin. While it is a design provider for using OpenWGA web applications as Wikis it also is a web application itself, providing the Wiki online help. Both usage cases use the same Wiki design, but while the first may use any data entered by users the second will provide the contents of the plugin content store, which contains the help also in Wiki design.