Every application needs some settings based on which it operates. For example, if there is a problem and an email needs to be sent to the site admin. The site mail admin address needs to be provided to the application. These can be different for different environments even for the same project. These miscellaneous settings are required to tell the application how to behave or set some level of control that we may want to alter from time to time. Taking the same example, the admin may change and we may need to change the admin email address without much worry.
There could also be application specific settings like a generic Tax rate that applies to all products in the system, and we may want to be lazy and not provide that for every product or category and have a single global setting run that.
Settings only provide the data, how they are intepreted can be always further customized by the application in some cases.
As will be clear through the rest of this document, configurations (or settings), are @ 3 levels in your application:
Namespace allow us to categorize our configurations. For example all site related configurations may come other site. As a sub category to site, all site email related configurations may come under site.mail or say some admin setting related to image compression of uploaded images under site.upload.
These standard rules apply to namespaces:
Configurations are mostly cached (stored in memory for quicker and more frequent access). Hence a change in a configuration may require a restart to the application at times (specially if its a file based static setting), or a clear of the cache. The system automatically refreshes (flushes) the cache in case of a dynamic configuration change, however its worth mentioning this since configuratiosn can be application specific and there could be corner cases where you find in your particular application a configuration is not automatically updated. If so, this should ideally be fixed.
These are set in .properties files in the Webserver project folder (/WEB-INF/classes), but available in display only mode by the admin interface.
One should not attempt to change these without consulting the developer, even if you have access to the file(s). The reason why they are kept static is because they are expected not to change while the server is running. Any change to them requires an update to your project base as well as a restart to the system.
For this reason it is also advisable to keep email addresses etc as people agnostic (company level) so that change in employees does not result in the email being defunct. One may argue that this should be a dynamic configuration, but it is also a reminder for good practice since, even if you had a dynamic configuration and the admin changed what is to say that you would remember changing the address. Hence best practiced should be adopted while setting these that always work better.
Static configurations can be of two types (by definition but not restricted to):
All static configurations are String (Text) format only.
The admin may demand direct control of some configuratons that need to control application behavior globally. Typically, we avoid the need for such configurations in the first place. The reason is that, every configuration has some scope of impact (where the change has effect), and defining a loose cannon is never a good idea from a mere discipline point of view. An example of this could for example, we want to control Flash SALE. Where, if we enable it, the site will start displaying some items on sale instantly. However, this can also be accomplished by having specialized Sal On/Off Button in the Catalog that acts on multiple products selected. Or even an ETL process, that has more context and definition around it.
In other words Dynamic Configurations, allow an easy way to create a setting whose intent only the application understands and has no pre defined meaning for the framework itself. These would be application specific to control miscllaneous scnearios that cannot be covered in any of the other admin sections or require frequent access by the application for performance reasons. In either case, the developer would define these based on your project needs and you can view them and change them from your admin.
The core format in which all configurations are saved is in String (Text only format), however the Dynamic panel allows based on development project needs, to create more fancy formats to allow the admin to administer it better.
For example in a more complex scenario for a pricing strategy we may want a Default pricing chart and present that information graphically that appeals to the Admin, rather than providing a more cryptic to read text string in JSON (true) format.
Since we know all configurations follow a namespace, it can be followed that for a given name space or sub namespace, all configurations within it (in the hierarchy) will be displayed when you select it from the Namespace(s) Drop down. The format of the namespace will change based on the configuration name (if anything specific is configured by the developer) or it will appear in default text only format.
A configuration view for a specific configuration can be customized by the developer / application configuration; to allow rendering of that configuration is a more user friendly manner. This includes its format and even displayed title. For example, in the screenshot above we can see the Default season pricing chart as a Table format and in addition, it's title is user friendly.
To add a new configuration, click the (+) button, put fille the complete namespace and fill the text box below with the configuration.
As dicussed earlier, dynamic configurations by themselves have no meaning unless developed (or coded) for. Hence it is unlikely that the administrator will have the need to setup a configuration first time. However if so, first time entry has to be in Text format and on Save, n the view and update mode if there is any format configured for the namespace entry, that format will take over.
Click the delete button. Once the configuraton is deleted, please be sure to test the part of your application that maybe affected by this change, since its application specific.
This should also remove it from the cache.Fille the updated data in the configuration and click the update button. Once the configuraton is updated, please be sure to test the part of your application that maybe affected by this change, since its application specific.
This should also update the cache.
