[2012-08-29] Add debug view of finalized YAML config tree

silverstripe / silverstripe-framework

Silverstripe Framework, the MVC framework that powers Silverstripe CMS

https://www.silverstripe.org

BSD 3-Clause "New" or "Revised" License

721 stars 821 forks source link

[2012-08-29] Add debug view of finalized YAML config tree #1577

Closed silverstripe-issues closed 9 years ago

silverstripe-issues commented 11 years ago

created by: @chillu (ischommer) created at: 2012-08-29 original ticket: http://open.silverstripe.org/ticket/7827

I haven't seen the config system in 3.0 used by a single community member yet. Part of this is lacking documentation ( silverstripe/sapphire#1456 ), but also the lack of transparency on how the config is actually compiled. In the few cases when I tried to debug the config, I've just changed "before/after" rules and other definitions by trial-and-error.

Add a tree view of the config tree (plain text indented)
Show all YAML files which are parsed, and the order in which this happened
(Optional) Add richer representation as a HTML unordered list (maybe with some simple expand/collapse logic?)
(Optional) Add metadata denoting the file origin for each config line

kinglozzer commented 10 years ago

I’ve had a quick play around with this here: https://github.com/kinglozzer/sapphire/commit/b2456b5b0d5a6a9c1a47d602c9f2333bd82f1e3b. Current appearance attached below, anyone have any comments on this implementation/suggestions for how to make this more useful? It’ll need a tree view of some sort - as it includes all the config values from the framework/cms so is quite long.

kinglozzer commented 10 years ago

Updated the draft version with a ‘tree’ view: https://github.com/kinglozzer/sapphire/commit/4da1ac79d9312facbb4c2d46dff1b82e9a5a7008. Mixing JS (and CSS) in with PHP is obviously horrible, what’s the preferred method for injecting CSS/JS like this? There are no obvious methods of adding CSS to DebugView, would it be better to construct a view manually?

screen shot 2014-03-20 at 20 58 40

tractorcow commented 9 years ago

Since DevelopmentAdmin can now be extended, this feature could easily be developed as a module. It isn't necessary to do this in core.

chillu commented 7 years ago

I disagree that "understanding your config" should be an opt-in module. The core config API is opaque as hell, reasoning about why one config value was chosen over another one is very hard. @micmania1 does your new config rewrite make tooling like this easier?

micmania1 commented 7 years ago

@chillu yep, it stores a bunch of metdata/history of each time a value is set and where that value comes from (eg. yaml file + yaml document name or private static + class name).