Hi Ingo
The @config is a good suggestion.
What I have been doing in my own code is that private static variables are always meant for the Silverstripe Config API unless they start with an underscore - e.g.
private static $_cached_value_for_foo = null;
For e-commerce, I removed all the private statics from the PHP classes, and I simply set them through a YML file, while at the same time keeping a list of Classes with their Statics and an explanation of what they are for. This then allows me to provide a DEV only list of all e-commerce configs available with. Grouped by Class and "area of interest", this makes for a good overview of available configs:
-- OrderProcess (area of interest for this example)
---- OrderStep (class name for this example)
------ send_email_to_customer (private static for this example)
-------- Exp: should the customer be sent an email with the invoice attached? (derived from a manually coded defining class)
-------- Default Value: YES (read from ecommerce.yml)
-------- Your Value: NO (provided by Config::inst()->get('OrderStep', 'send_email_to_customer') )
That symphony system looks very good.
I guess for me, it is important to know what problem are we trying to fix? I started this thread by basically saying - it would be good to have a fast and easy overview of available statics for a particular module.
Nicolaas