is there any code for extracting private statics

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi

We are working on increasing the quality of our modules. As part of this, we would like to make a full list of config options for each module.  I have two questions in relation to this: 

(1) Has anyone written a piece of code for extracting all the private statics of a module?  I am keen to write / find such a piece of code to map config options

Also ... I am wondering: 

(2) Is there a trend now of not adding the actual private static to the class but still using it - e.g.

you do not add:

private static $my_var_goes_here = 'foo';

to a class, 

but in the same class, you use:

$myVar = $this->Config()->get('my_var_goes_here');

And of course, you define this static in your yml config file. 

Any ideas appreciated. 

--

Nicolaas 

[Loz Calver]

Hi Nicolaas,

(1) Has anyone written a piece of code for extracting all the private statics of a module?  I am keen to write / find such a piece of code to map config options

I’m not aware of anything that can do this, at least not something pre-packaged. In theory you might be able to construct a new SS_ConfigStaticManifest instance that points to your module directory instead of the document root - though I’ve never tried that. It’s also worth noting that the class will be completely different in SilverStripe 4 (instead of parsing PHP files on every dev/build, it will just use ReflectionProperty to access values on the fly).

I would expect that hand-written documentation with examples of valid values and their use-cases would be more useful than anything programmatically generated, though perhaps you could just use it to build a list that you can then check off against as you write documentation?

I’m not sure of the best approach to build something like this - it probably depends on what you want it to be able to do. Assuming you just want a list of available options (rather than their actual values), I’d probably just try something that can parse PHP files docblocks. So you’d give the tool your module directory’s path, it’d then scan and look for properties with @config and extract what info it can.

(2) Is there a trend now of not adding the actual private static to the class but still using it

I don’t believe there’s a trend of doing this, it probably just comes down to the author’s preference over whether values sit in PHP or YAML. My preference is to declare the “default” values in PHP, then any other modules and users can override them in YAML more easily. If they’re set in YAML, and other modules attempt to override them in YAML, then you’re more likely to have headaches with the order that config values are merged (i.e. Before: and After: in YAML header blocks).

Loz

[Michael Strong]

You could probably do this by reading all cache files directly and mapping out the keys that way. Like Loz said, in SilverStripe 4 the way it reads private statics from PHP classes is different - you would need to go through the class manifest and and use ReflectionClass to figure out its private statics.

Further to this, configuration is variable (eg. if environment type is dev or a constant is defined etc.) so this sort of thing becomes complex very quickly.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Michael Strong | Developer
SilverStripe
http://silverstripe.com/

Phone: +64 4 978 7330
Skype: micmania1

[Nicolaas Thiemen Francken - Sunny Side Up]

Thank you for your great replies.

While in an ideal world I would write up example of every config option it might be more effective to just list them programatically for starters. I think in 80% of the cases this will be useful... e.g. 

Blog

  number_of_entries_per_page: 10

A setting like this does not need explanation ... but it is great to have all these settings in a list for a quick review.

I think what you seem to suggest is to have something like this:

https://gist.github.com/sunnysideup/460437b3e0db275b88653455d3709d6c

Is this a good approach?

Thank you again for your detailed responses.

Nicolaas

[Ingo Schommer]

I've used a custom @config PHPDoc marker when initially adding core support for the Config API, although that convention is neither documented nor is the metadata consumed by anything (yet). It could help with your reflection approach (since not all statics will be config parameters).

Ideally we'd have a way to define a configuration schema, rather than just this loose relationship between statics and the SilverStripe Config API.

Symfony does that with some interesting fluent syntax: http://symfony.com/doc/current/components/config/definition.html

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

[Nicolaas Thiemen Francken - Sunny Side Up]

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​

[Nicolaas Thiemen Francken - Sunny Side Up]

I also wonder if there is ( / there should be ) a way to exclude a private static from the config layer... (e.g. if it starts with an underscore).

[Michael Strong]

I don't think that would provide any value. If something doesn't belong in config, then it shouldn't be called from config. 

Remember, in SS4 this inspection of the property names would be happening at runtime, every time a new config variable is called

On 11 August 2016 at 12:34, Nicolaas Thiemen Francken - Sunny Side Up <nfra...@gmail.com> wrote:

I also wonder if there is ( / there should be ) a way to exclude a private static from the config layer... (e.g. if it starts with an underscore).

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--