IRCLogs20101118 (diff)

You must first sign up to be able to contribute.

Changes between Version 1 and Version 2 of IRCLogs20101118

lsmith (IP:
11/18/10 22:06:19 (7 years ago)



  • IRCLogs20101118

    v1 v2  
    55== Console dependency injection == 
    6 .
     6The proposal is to turn the CLI commands into services. The main concern is that this will add yet even more services to the dumped DIC php class which would be loaded when rendering web pages. It was decided that at this point its not even clear at what size this will really become an issue. More importantly any such issues should be mitigated by keeping the CLI command services separate from the rest. This way they could be kept out of the DIC when rendering web pages: "We can also have a AppKernel and a AppCliKernel that extends AppKernel and just override the container configuration" (volunteers needed
    88== Best practices for dynamic service definitions == 
    9 .
     9"The issue here is that for example in DoctrineBundle we have dynamic services and right now these services are essentially hardcoded in the extension class." We quickly agreed to take an approach first used by the security component which defines template services which can be tweaked by the end user in the normal way, which then get copied and dynamically adapted by the given bundle. Most of the discussion then revolved about how to clean these template services so that they do not end up in the dumped DIC and how such template services should be identified. The tentative agreement was to "tag" them as templates in the service definition. Furthermore removing these services should either be done in the Extension base class or in the DIC dumper itself (volunteers needed
    1111== Security context serialization between requests == 
    12 .
     12The issue here is the question of how to prevent stale users as data about users is "cached" in the session. More over the problem of choosing the right provider to reload the user. As a first step it was agreed to require and store a unique of the name of the provider to ensure that the right provider is chosen when unserializing (Thibault volunteered to take a look at There are still open concerns here, like what happens with active sessions if the provider name is ever changed. Also there is still a need to implement different strategies to update the "cached" data in the session: on change, on very request, at certain intervals, on the next request after a change etc. Finally the "issue about sharing the security context remains, right now it is shared"
    1414== Current status and roadmap of the form framework and the admin generator == 
    15 .
     15Bernhard stated that "the roadmap is to finish the form and Validator by the end of the year". The admin generator will come after that, potentially in cooperation with the Symfony CMF team. It will be a bundle and its not yet clear if it will be part of the core, though several people said that they think its very important to have it be part of core. Bernhard said it would be helpful if people would help verify the open bug reports (volunteers needed The next big task aside from fixing bugs is thinking about how JS integration into form elements should work. In a little side node Jordi asked Fabien what the next big things are for Symfony2 core and Fabien said that the main thing to do now is to fix bugs. Fabien also mentioned that he has some unfinished code for handling ACL's that he would be willing to share with interested people
    1717= IRC logs =