I have proposition to use ./app_name/console container:debug instead of full service.* parser (added in Symfony 2.1).
It will much more faster (and more powerfull) than scan all files.
Another option is create parser per bundle (app -> find app kernel -> resolver bundle ) for priorites and bundles dependecy, and next start parsing from app_name/config/routing.yml etc...
I can do it ;)
@zulus thanks for the suggestion. I've already created a pull request in symfony symfony/symfony#5740 to make parsing of the output easier.
I am planning to rewrite the whole service/routing parsing from scratch. I've also got some input from @schmittjoh to parse the services and routes directly from the dumped and cached servicecontainer in cache/*/*debugProjectContainer.php.
The disadvantage from using the container:debug task is that we would need to rely on a working php executable setup, which i'd try to avoid.
Parsing the dumped container would be pretty easy to do. Unfortunately i'm busy with a large project atm, but your proposal is definitely on my roadmap.
If you have time to look at it, i'd be happy to merge your PR!
cache/_/_debugProjectContainer.php sounds much better
I'm closing this ;)
@zulus @schmittjoh i've refactored the service parser to use the dumped .xml inside the cache/dev folder: 9a36c9f
Any suggestions on how i should choose the enviromnent to parse? Should this be configurable, or will it confuse people?
Hmmm, can you parse all enviroments and put env info in service list grid?
+and/or allow user to add and select/deselect enviroment?
@zulus implemented in 1.0.94. The dumped container can be selected in the project preferences page and defaults to app/dev/app**DebugContainer.xml