What's the deal with _config?

[Uncle Cheese]

So I knew that SS3 was introducing a whole new configuration layer, and I remember Hamish's blog post about it, but it wasn't until I added a Director::addRules() to my _config.php yesterday and things blew up that I realized I am grossly undereducated on how this thing works!

I haven't been able to find good documentation. Maybe I'm not looking hard enough.

What goes in _config/*.yml that used to go in _config.php? What's the upgrade process?

[Frank Mullenger]

Hey UC, there is some documentation on this page under 'Object Static functions replaced with new Config class':

http://doc.silverstripe.org/framework/en/trunk/changelogs/3.0.0

I found the oembed stuff to be a useful example:

https://github.com/silverstripe/sapphire/blob/3.0/_config/Oembed.yml

https://github.com/silverstripe/sapphire/blob/3.0/oembed/Oembed.php#L17

There are also some before/after rules which I haven't used but they don't work between config yaml files I believe:

https://github.com/silverstripe/sapphire/blob/3.0/core/Config.php#L161

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/3ZFiMn8NKx4J.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Marcus Nyeholt]

On the subject of Config, has there been much performance analysis done on it yet. I haven't really dug too deep into it yet, but have noticed on my xhprof runs of SS3 systems that Config:: calls are regularly amongst the top 10 (see attached). This is to be somewhat expected given the amount of static lookups needed in SS, but I'm curious as to whether it's worth digging deeper to see whether more savings can be made

[Hamish Friedlander]

There's definitely savings still to be made.

The biggest issue is that statics live at the bottom of the merge stack, but at the moment can change at any time, so the stack must be remerged on lookup.

For 3.1 hopefully the manifest builder will pre-extract the values of all statics, which will then, as far as the config layer is concerned, be immutable. Once we're doing this we can require all config statics be private, which will catch any attempt to modify directly.

Then we can cache inter-request the entire merged value for any given class  and property, with just the changes from config::set to merge on top

There's a lamentable dearth of documentation on the config system, and now 3.0.1 is out improving that is probably my next task. 

Hamish Friedlander

<config-load.png>

[Ingo Schommer]

There's a ticket for the config docs: http://open.silverstripe.org/ticket/7141

I think we also need a way to visualize the config tree for debugging purposes.

Particularly with overriding director rules, I've pretty much guessed

which rule should be marked as "before" and "after",

by loading the new URL endpoint and check what happened.

Given that config values aren't immutable, I think the most convenient

way would be something like Config->debug() which can be called inline

at various points of the execution change. As we get more towards immutability,

a dump at the start/end of the request will become more useful

(maybe through the new debug toolbar GSOC project?).