Lots of the smart features in kbmMW utilize attributes for defining various metadata for parts in your smart kbmMW based application server.
For example the kbmMW_Service attribute that defines various things about the service class. However the only way to tell kbmMW to grab the settings for the service definition from a configuration file, required you to either use the old (non smart) way of defining services and registering them, or it required you to lookup the service’s service definition (TkbmMWCustomServiceDefinition and descendants) after the AutoRegisterServices call, and modify its properties.
And that is not smart.
So of course kbmMW needs to be smart. It should be as easy as possible to define your stuff, so you only have to focus on your business code and not on all the framework related stuff around it.
All settings based attributes will now have access to fetch configuration settings directly. Settings based attributes includes all attributes descending from TkbmMWCustomSettingsAttribute. Currently that includes kbmMW_Auth, kbmMW_Service, kbmMW_Rest, kbmMW_Config, kbmMW_HTTP, kbmMW_Ignore, kbmMW_Table and kbmMW_Field attributes.
The above attribute, placed before a kbmMW service class definition, tells kbmMW what the suggested name for the service is, which version it has, how many instances will minimum be spawned and how many will maximum be spawned. As you can see, the minInstances and maxInstances settings has a “different” syntax than usual. Instead of just containing a simple number, it now contains a $(configpath[=defaultvalue]) formatted value.
Basically minInstances now looks in the default configuration manager (referred to via the global variable Config), for a value at the configuration path service.smartDemo.minInstances. If one is found, then the read number will be used. In the above example there is also a default value (32), in case there are no value at the configuration path.
This attribute can be placed multiple places, like before methods or as in this case, before the service class definition, where it defines who have access to accessing the service. Usually grant would have the value true or false, but in this case we look the value up from the configuration at the configuration path auth.service.grant. Default value is true.
I recommend using the configuration manager including these new features, rather than any homecooked configuration system, simply because it provides an application wide simple way to access and store configuration data in any of the formats supported by kbmMW (Ini files, Windows registry, XML files, JSON files and YAML files in addition to a virtual configuration manager which for example could be used to store the configuration in a database).
