-
Notifications
You must be signed in to change notification settings - Fork 1
Features
The usefulness of this plugin is not always immediately clear. That is why we'll first look at the typical configuration problems that you run into as a dotCMS plugin developer. We'll later explain how each of these problems are solved by this plugin.
Suppose you work in a company that uses separate dotCMS instances for development (DEV), user acceptance testing (UAT) and production (PROD). Often you'll find that you need a slightly different plugin configuration for each instance. For example: the webservice backend that the plugin talks to is different on each server (you don't want the DEV instances to talk to the PROD backend) or other e-mail addresses must be used for sending out confirmation e-mails. To copy a new version of a plugin from DEV to UAT and from UAT to PROD would require a change in the configuration of that plugin each time. This process is extremely error prone: people forget to make the required changes and before you know it you'll have test data in your production system. Ideally you'd like to be able to set up the instance specific plugin configuration only once: when installing dotCMS, and copy and paste the entire plugin folder from one instance to the other without having to worry about forgetting to change the configuration after the copying.
Usage of the instance specific plugin configuration
Suppose you are developing a plugin that takes the information that a user posts on a website and sends it to some external webservice. Now suppose this external webservice takes a number of additional parameters including an API key that is different for each host the user posts the information on. If your dotCMS instance has only one host that uses the plugin then you could put the API key in the plugin's configuration. But if multiple hosts use the plugin you'd have to store an API key per host somehow. You could store this information as an extra field in the dotCMS host structure, but you might not want to expose this information in the dotCMS admin. What to do?
Usage of the host specific plugin configuration
Suppose you are developing the external system that the dotCMS plugin will communicate with using webservice calls. If multiple developers are building the external system on their own machines then the dotCMS plugin will need a different URL for each developer. This is because the IP address in the webservice URL will need to point to the developer's local machine. This can be done by providing each developer with their own dotCMS instance, but that can be cumbersome. We would like to install one instance of dotCMS on some shared server and have each developer use that instance. DotCMS would have to have a way to let the plugin know to connect to the external system on the machine of the developer that is doing the testing. An extra benefit is that the frontend developers could work on that same server. All changes that they make to the site are immediately visible for all the developers of the external system when they do their testing.
Usage of the client specific plugin configuration
Suppose your plugin needs a complex nested XML structure in its configuration. The default dotCMS configuration only allows name/value pairs in the "web-ext.xml" and "plugin.properties" configuration files, so this is not possible without losing semantics. How to solve this?
Usage of the complex plugin configuration
Suppose you want to add simple or even complex configuration to each host (independent of any plugins). You could add extra fields to the host structure in dotCMS or to a 'global variables' container that you include on all the pages, but that will only take name/value pairs. These value are also stored in the dotCMS database, making it almost impossible to include in source control which can be an issue. Where to put this configuration?