Enhancement
Module configuration
Issue description
One open problem is how modules can be adjusted in their behavior by configuration, so that subsequent module updates will not cause any problems. This would work with an abstract topic type Module configuration which is subtyped in the origin store. There is an association type for connecting the options to the module. The module itself may have exactly one instance which are the options. These may be edited at the client. Optional fields must use a default value. Missing mandatory options – if the administrator forgets to configure the module – will throw a ModuleOptionMissingException (a sub class of DeveloperException).
Developer comments
After giving this some thought, i am still not quite sure. The simplest solution would be to have a specific topic type TT1 representing the configuration for module M1, just like any ordinary domain topic type. An instance T1 of TT1 is created in the origin store of the module and becomes a piece in the module. In the code the configuration is accessed via the tobject for T1. This would already implement the core of the functionality. Now there is some nice to haves:
* An abstract topic type _Module configuration_ would make it possible to list them in the index for modules. It would also become clear that TT1 is not a domain topic type, but a schema topic type.
* The association type between module and module options is also helpful, since otherwise how does the module user know that there is a configuration. But it should *not* be editable, neither at the options, not at the module. TT1 must be created in a service where the instance (there can be only 1) is also created immediately. These instances cannot be deleted. The service can only be used in the origin store.
In this case the name of the topic type, the sub type of module configuration, almost becomes irrelevant. Any module configuration topic type will have exactly one instance. Thus i am having second thoughts if that is really the right approach. A simple PHP class could server as the module configuration as well. It simply would use static members. After all the configuration exists because the store exports source code together with a schema. If a module would not have source code, there would be no need for any configuration.
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.