Closed pcambra closed 7 years ago
Hey there, great news, thank you for finding Kint useful!!!
I'm trying to come up with a solution, the autoloader I currently use is dead-stupid (does the job though)...
What you are trying to accomplish would be best solved by custom configuration options and that is my number one concern in the past several months - to provide a comfortable way to configure Kint settings for the end user - and I can't seem to find a good solution.
Hm, would writing a kint config.php
file to Kint root dir be plausible to your implementation? If not, just say so, I'll try to engineer some better way.
Thanks for the answer! The way we're getting the library in the future (we're doing this for Drupal 8 and that's in the works at this point) is through composer, most probably, so I don't think we can add a config.php just in the root dir of the library. We could do it now, but it won't last a long time. How would the config.php work for adding a parser? Is there any way to place this config file outside the library and getting it loaded?
I think an approach similar to the global setting properties on the Kint class would work better for us for now.
It's not that great, but it's an existing pattern and should be easy to extend for this? Problem is possibly only that the structure would need to be changed so that classes/files can be loaded that aren't in the same directory.
Well, these:
https://github.com/raveren/kint/blob/1.0.0-wip/Kint.class.php#L45
are all configuration options and as you can see it's kept as simple as possible because I don't see any other decent solution. One way to configure Kint is to alter these options after Kint can be autoloaded. E.g.:
require '/Kint.class.php';
Kint::$theme = 'solarized-dark';
I'm guessing this is not the worst solution, would it work for you? If so, I'll make sure it's possible and add a configurable autoloader option for parsers and alternate class display.
If I get confirmation that it's the way to go, I will first need to implement a method of not breaking anything if configuration options change in the future. I.e. you're calling Kint::$expandedByDefault
in your code and this option gets removed or renamed, and your existing code does not cause warnings...
In any case, what you're trying to do is definitely possible and I'll help you in any way I can, so don't worry about integration :)
I'll just update you on this, I've been working a lot to rebuild the current configuration system to something manageable and should be ready with a minimal viable implementation in the few upcoming days.
It will have the final configuration API that will no longer change in the future, so bear with me for a couple more days :)
Thanks @raveren. FYI, kint is now part of the devel project for Drupal.
Yay! Sorry I've been out of touch, I just returned from a trip and will be developing Kint heavily in the coming weeks.
Let us know when you make any progress on this one. Thanks.
Any news?
We're doing an integration of Kint in the Devel module for Drupal 8: https://drupal.org/project/devel and one of the things we'd need is to provide custom parsers to inspect various properties and methods that are Drupal specific but seems that the discovery of the parsers only happens in the own Kint directory.
Could we add some sort of autoloader to load parsers from elsewhere (autoloader i.e.), I'm willing to provide a PR if you point me the right direction.
This is how one our parsers would look like: https://gist.github.com/Berdir/9335736