Console dependency injection
The 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 http://trac.symfony-project.org/ticket/9273).
Best practices for dynamic service definitions
"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 http://trac.symfony-project.org/ticket/9274).
Security context serialization between requests
The 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 http://trac.symfony-project.org/ticket/9275). 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".
Current status and roadmap of the form framework and the admin generator
Bernhard 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 http://trac.symfony-project.org/report/24). 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.
Nov 18 10:58:48 <lsmith> ok .. i closed the vote Nov 18 10:59:00 <lsmith> avalanche123: sure lets go Nov 18 10:59:08 <avalanche123> hi everyone! Nov 18 10:59:19 <avalanche123> the first topic on the list is the console DIC Nov 18 10:59:26 <avalanche123> or rather I think it makes sense Nov 18 10:59:37 <avalanche123> to register all console commands as services in DIC Nov 18 10:59:43 <avalanche123> for easy testing and mocking Nov 18 10:59:47 <avalanche123> more here - http://avalanche123.com/post/1319532278/symfony-console-commands-and-dic Nov 18 11:00:09 <avalanche123> the post there includes an example of rewriting the existing command Nov 18 11:00:17 <avalanche123> in DIC compatible way Nov 18 11:00:23 <avalanche123> and making it testable Nov 18 11:00:46 <lsmith> there is a pull request too https://github.com/fabpot/symfony/pull/70 Nov 18 11:00:55 <avalanche123> lsmith is correct Nov 18 11:01:11 <avalanche123> there is a pull request, but it doesn't include the rewriting of existing commands Nov 18 11:01:23 <lsmith> i guess the main concern against adding this is that it will add yet more services that will be cached in the DIC class Nov 18 11:01:31 * Garfield-fr has quit (Quit: ⏏) Nov 18 11:01:41 <avalanche123> yes, fabpot said, that that would make the container much bigger Nov 18 11:01:42 <lsmith> which is a growing concern even before adding this Nov 18 11:02:00 <lsmith> are there any other concerns? Nov 18 11:02:25 <avalanche123> and I agree, that it would, however, OpenSky's largest DIC is 201,327 bytes Nov 18 11:02:31 <avalanche123> which doesn't seem that big Nov 18 11:02:36 <avalanche123> and we ahve lots of stuff there too Nov 18 11:02:40 <avalanche123> *have Nov 18 11:03:06 <avalanche123> so maybe we should in a feature branch convert all commands to services and see how much bigger the container gets?... Nov 18 11:03:07 <lsmith> right .. but opensky has taken the "multiple app" approach .. which might be the best practice to handle this concern Nov 18 11:03:15 <avalanche123> true Nov 18 11:03:18 <fabpot> another concern is that you will "load" these service definitions when calling your app from the web, where you will never have a need for them Nov 18 11:03:39 <avalanche123> yes, I agree, that its sub-optimal Nov 18 11:03:53 * bschussek (~email@example.com) has joined #symfony-dev Nov 18 11:03:56 <avalanche123> I was thinking about how to split container for quite a bit Nov 18 11:04:04 <lsmith> right .. if we were to keep a separate DIC with all the CLI services, that falls back to the web DIC in case a missing service is called, then this would "fix" that concern Nov 18 11:04:10 <fabpot> also, commands are like controllers, they hardly need to be tested, as the meat of the command should be in the model Nov 18 11:04:20 <fabpot> also because then, it can be resued in another context Nov 18 11:04:21 <lsmith> but it would mean that the services need to be managed in separate configs Nov 18 11:05:11 <lsmith> well testability is also not my main concern here .. but extensibility .. though i have not yet tried to extend/modify a CLI command Nov 18 11:05:11 <avalanche123> I see Nov 18 11:05:32 <avalanche123> doctrine commands for example could benefit from that Nov 18 11:05:39 <fabpot> lsmith: what do you want to "extend"? Nov 18 11:05:51 <avalanche123> since there would not be a need for bundle specific command classes that extend the base ones anymore Nov 18 11:05:58 <fabpot> avalanche123: you mean, refactoring code to a "model" Nov 18 11:06:11 <avalanche123> not sure Nov 18 11:06:14 <avalanche123> what I mean is Nov 18 11:06:26 <avalanche123> DIC gives you the benefit of configuration Nov 18 11:06:33 <avalanche123> which is not available with convention based Nov 18 11:06:38 <avalanche123> command instantiation Nov 18 11:07:00 <avalanche123> so doctrine for example needs to create these dummy command classes in their bundles Nov 18 11:07:13 <avalanche123> just because there is no way to point to the real ones Nov 18 11:07:39 <avalanche123> am I making sense? Nov 18 11:07:44 <lsmith> fabpot: for example you might take issue with how doctrine does DDL changes and you want to ensure that when doing DDL .. its using a different username .. a bit contrived but an example of where you might want to "extend" a core CLI command Nov 18 11:07:45 <fabpot> avalanche123: not sure ;) Nov 18 11:07:49 <avalanche123> :) Nov 18 11:07:54 <jwage> why is the size of the DIC problem? I mean of course you have a point where the size can cause problems but I think the point where the size is a problem is not realistically going to happen Nov 18 11:08:16 <jwage> has anyone tested or done any benchmarks or anything with a massive DIC? Nov 18 11:08:24 <avalanche123> jwage, I think we need to Nov 18 11:08:32 <avalanche123> otherwise its just an empty argument Nov 18 11:08:38 <jwage> I just can't imagine that it really is a problem Nov 18 11:08:49 <fabpot> lsmith: but a command is just a way to give your model some input and output something, nothing more Nov 18 11:08:54 <avalanche123> OpenSky's DIC is 4500+ loc Nov 18 11:08:59 <jwage> i think you;d have to have like thousands and thousands of services Nov 18 11:09:01 <fabpot> jwage: more code == less speed with PHP Nov 18 11:09:03 <lsmith> but isnt keeping the service configs separate with a "chained" DIC in CLI mode a pretty simple way to solve the issue if necessary Nov 18 11:09:03 <jwage> which is unrealistic Nov 18 11:09:28 <jwage> fabpot: i know, technically that is right, but the size to speed loss is so small i bet Nov 18 11:09:28 <avalanche123> lsmith, I think I agree Nov 18 11:09:33 <jwage> with the size of DIC we're dealing with Nov 18 11:09:38 * cliassom (~firstname.lastname@example.org) has joined #symfony-dev Nov 18 11:09:56 <avalanche123> so maybe we fix the size problem when it really becomes a problem? Nov 18 11:09:57 <fabpot> jwage: it's not (and I did some benchmark some months ago) Nov 18 11:10:06 <jwage> ok Nov 18 11:10:09 <fabpot> avalanche123: my point is not just about the size Nov 18 11:10:18 <jwage> so in opensky then since we have multiple apps this keeps the number of services low Nov 18 11:10:20 <fabpot> it's also about "polluting" the web DIC with non-web services Nov 18 11:10:20 <lsmith> avalanche123: thats my thinking .. i dont really see that the size issue will put us into a corner we cannot fix Nov 18 11:10:22 <jwage> b/c we only enable what that app needs Nov 18 11:10:26 <jmikola|w> sorry for the late comment (just returned to desk) - i think the issue of loading console commands in http-only apps is an issue, perhaps solved by a configuration option in symfony to control the loading of things Nov 18 11:10:31 <jwage> instead of having everything in one app and everything always enabled Nov 18 11:10:35 * cliassom (~email@example.com) has left #symfony-dev Nov 18 11:10:47 <jmikola|w> if console commands were tagged in DIC, an option could be employed to decide if you wanted to register all tagged console commands Nov 18 11:10:53 <bschussek> fabpot: what about having separate DICs for web and CLI? Nov 18 11:10:57 <avalanche123> but you might want to run command from an http app Nov 18 11:11:06 <avalanche123> say you have a message queue Nov 18 11:11:08 <avalanche123> rabbit Nov 18 11:11:12 <fabpot> avalanche123: NO Nov 18 11:11:17 <avalanche123> :) Nov 18 11:11:21 <avalanche123> ok, point taken Nov 18 11:11:27 <fabpot> avalanche123: you would probably reuse the code from your model, not the command itself Nov 18 11:11:31 <lsmith> btw .. 4 more minutes in the timebox Nov 18 11:11:33 <jmikola|w> or a shared service :) Nov 18 11:11:57 <avalanche123> yeah, I concur that is more semantically correct Nov 18 11:12:04 <fabpot> bschussek: probably possible Nov 18 11:12:16 <fabpot> bschussek: don't know how much complexity it would add though Nov 18 11:12:23 <jmikola|w> bschussek: wouldn't the be accomplished by just separate apps for web/cli? Nov 18 11:12:23 <avalanche123> still I'd like to test my commands, I don't see how that could be done without DIC Nov 18 11:12:32 <jmikola|w> or you wouldn't want to duplicate kernel code Nov 18 11:12:34 <jwage> fabpot: does spring have a console? Nov 18 11:12:46 <lsmith> well it means for one that the services for commands need to be specified in a separate file (i dont really think that tagging is the way to go) Nov 18 11:12:57 <fabpot> avalanche123: to make it clear, I'm not against introducing services for CLI commands Nov 18 11:13:17 <jmikola|w> fabpot: practically, the implementation is just loading things tagged as CLI commands, right? Nov 18 11:13:24 <jmikola|w> i haven't seen the pull request Nov 18 11:13:27 <fabpot> ok, I think I have a solution Nov 18 11:13:50 * avalanche123 held his breath Nov 18 11:13:51 <jwage> could we just have a cli version of the DI? Nov 18 11:13:55 <fabpot> as lsmith said, CLI commands are registered in another configuration file Nov 18 11:14:01 <fabpot> which is not loaded by the default Kernel Nov 18 11:14:09 <fabpot> but only when in console mode Nov 18 11:14:48 <lsmith> ok .. sounds like we have a task for someone to take over :) Nov 18 11:14:54 <jmikola|w> so this is an additional DI config, sharing the same application config? Nov 18 11:15:20 <fabpot> via another registerContainerConfiguration() method registerContainerCliConfiguration() for instance Nov 18 11:15:22 <jmikola|w> i assume CLI services would still want the main (i.e. web) di config Nov 18 11:15:42 <lsmith> ok .. seems to me like we made progress .. Nov 18 11:15:48 <lsmith> time to move to the next topic Nov 18 11:15:55 <lsmith> we have a bit of a 4 way tie here Nov 18 11:15:58 <fabpot> or we can also have a AppKernel and a AppCliKernel that extends AppKernel and just override the container configuration Nov 18 11:16:09 <avalanche123> fabpot I like it Nov 18 11:16:09 <lsmith> i propose we go to "Best practices for dynamic service definitions" next Nov 18 11:16:27 <avalanche123> lsmith, mind introducing the topic? Nov 18 11:16:36 <pgodel_work> I like the AppCliKernel idea Nov 18 11:16:37 <lsmith> so the issue here is that for example in DoctrineBundle we have dynamic services Nov 18 11:16:52 <lsmith> and right now these services are essentially hardcoded in the extension class Nov 18 11:16:53 <jmikola|w> lsmith: is this anything like the dynamic stuff inside security component too? Nov 18 11:16:54 <jwage> lsmith: i think we need services that are templates Nov 18 11:16:56 <jwage> tagged as templates Nov 18 11:16:57 <fabpot> lsmith: any conclusion before on the first topic? Nov 18 11:17:02 <jwage> and are never actually generated in the DIC Nov 18 11:17:10 <jwage> they are only used as a template to clone in the *Extension.php Nov 18 11:17:21 <jwage> so for example I can have a DI configuration for a Doctrine\DBAL\Connection Nov 18 11:17:25 <fabpot> jwage: that's what we have in the security extension Nov 18 11:17:32 <jwage> and it is used as the base for creating all connections in the *Extension.php Nov 18 11:17:35 <fabpot> I have a special security_template.xml config file with templates Nov 18 11:17:44 <lsmith> fabpot: my understanding is that we feel we can handle the issue of services for commands, by separating the CLI specific services Nov 18 11:17:44 <jwage> and we just load it in the *Extension.php ? Nov 18 11:17:45 <fabpot> and the services there are removed at the end of the configuration process Nov 18 11:17:48 <jwage> ah Nov 18 11:17:49 <jwage> ok Nov 18 11:17:50 <fabpot> so they don't end up in your container Nov 18 11:17:50 <jwage> hmm Nov 18 11:17:54 <jwage> couldn't we just add a tag? Nov 18 11:18:04 <jwage> and have it ignore the ones with that certain tag Nov 18 11:18:11 <jmikola|w> jwage: https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/SecurityExtension.php#L146 Nov 18 11:18:36 <fabpot> jwage: that can be a convention you have, sure Nov 18 11:18:48 <jwage> ya i just dont want each extension to have to manually remove them Nov 18 11:18:51 <jwage> and reimplement the same thing Nov 18 11:18:56 <jwage> over and over Nov 18 11:19:26 <jmikola|w> so adding some basic helper methods in Symfony\Component\DependencyInjection\Extension\Extension to handle this convention? Nov 18 11:19:45 <jwage> ya i dont want to have to do this Nov 18 11:19:45 <jwage> https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/SecurityExtension.php#L146 Nov 18 11:19:47 <jwage> everytime Nov 18 11:19:56 <jwage> in the configuration i should be able to just tag a service is "template" Nov 18 11:19:57 <jwage> or something Nov 18 11:19:58 <lsmith> jwage: so we add a new attribute "template" ? Nov 18 11:20:11 <fabpot> jwage: sure Nov 18 11:20:12 <jwage> right, and then the builder won't generate those services Nov 18 11:20:13 <Seldaek> why not do this in the Container Dumper ? Nov 18 11:20:13 <lsmith> and those are never written in the phpDumper Nov 18 11:20:20 <jwage> Seldaek: thats what we're suggesting Nov 18 11:20:26 <jwage> instead of each extension having to reimplement the same removing code Nov 18 11:20:36 <lsmith> ok sounds like a plan Nov 18 11:20:37 <Seldaek> well, yeah, but suggestions sounded more like helper code in DI Extension Nov 18 11:20:40 <fabpot> jwage: no, we are suggesting to do that in the Extension, not in the Dumper Nov 18 11:20:45 <jwage> hmm Nov 18 11:20:53 <Seldaek> so I'd like to clarify the suggestion :) Nov 18 11:21:06 <jmikola|w> lsmith: would that possibly ruin the convention that loaders and dumpers won't change things? Nov 18 11:21:08 <jwage> this just seems weird Nov 18 11:21:09 <jwage> https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/SecurityExtension.php#L146 Nov 18 11:21:18 <jwage> why not just get the tagged templates and remove them before dumping? Nov 18 11:21:36 <lsmith> hmm i guess because then you could indeed have a different behavior Nov 18 11:21:44 <fabpot> jmikola|w: exactly. Dumpers just, well, dump the container Nov 18 11:21:49 <lsmith> i guess atm in the first request it doesnt actually use the dumper Nov 18 11:21:50 <jwage> ok Nov 18 11:22:00 <johanness> you could also load the templates into a different container builder and clone them from there Nov 18 11:22:01 <jmikola|w> fabpot: does DIC generation just use phpdumper at the moment? Nov 18 11:22:01 <avalanche123> I think that is what will happen, just the "remove before dumping" takes place in Extension Nov 18 11:22:07 <johanness> instead of loading them into the actual container Nov 18 11:22:33 <fabpot> jwage: but I think it's fine to do that in the extensions as this is the only place where it makes sense to use templates, right? Nov 18 11:22:46 * maerlyn has quit (Quit: Leaving) Nov 18 11:22:54 <fabpot> lsmith: I don't know how many topics we have today, but I will need to leave in 30 minutes Nov 18 11:22:56 <jwage> yes i just worry that we leave it up to the developer to reimplement this removing everytime and it being inconsistent, or they don't do it Nov 18 11:23:04 <jwage> and they end up using templates and having the services in the DI Nov 18 11:23:12 <fabpot> jwage: no, we will provide a special tag and the method to remove them Nov 18 11:23:15 <jwage> ok Nov 18 11:23:16 <lsmith> fabpot: k Nov 18 11:23:19 <jwage> that works for me then Nov 18 11:23:22 <Seldaek> but why provide a method to remove them Nov 18 11:23:27 <Seldaek> why not just make it automatically Nov 18 11:23:33 <Seldaek> after calling the extensions Nov 18 11:23:33 <jwage> i just dont wanna have to to the $servicesToRemove = array(); foreach ($servicesToRemove Nov 18 11:23:34 <jwage> etc Nov 18 11:23:34 <fabpot> Seldaek: being explicit Nov 18 11:23:42 <Seldaek> well, it's explicitly tagged Nov 18 11:23:55 <bschussek> I agree with Seldaek Nov 18 11:23:56 <jwage> im not sure i see any reason not to remove it automatically Nov 18 11:24:05 <jwage> if its tagged as template, u dont want it as a real service Nov 18 11:24:11 <Seldaek> if you just call $this->removeTaggedServices(), and don't specify which you want to remove, it'll just remove all tagged templates for all extensions Nov 18 11:24:15 <fabpot> Seldaek: bschussek: jwage: I don't see where we will be able to do that automatically Nov 18 11:24:29 <jmikola|w> jwage: the logic for that shouldn't be in a dumper though Nov 18 11:24:32 <Seldaek> so either you do it all at the end, or you have to specify Nov 18 11:24:34 * wissl (~firstname.lastname@example.org) has joined #symfony-dev Nov 18 11:24:39 <fabpot> ok, I think we have a solution. Someone needs to work on an implementation now Nov 18 11:24:48 <jwage> i agree, if we have no way to do it properly then im ok with having to call the method explicitly Nov 18 11:24:59 <lsmith> yeah .. i think we have agreed on the principle Nov 18 11:25:09 <avalanche123> that could be implemented in the base Extension class Nov 18 11:25:13 <lsmith> the rest is detail .. which can still be discussed in the pull request Nov 18 11:25:24 <Seldaek> jwage: so the method is just a foreach that calls ->remove() on the array you give it? sounds a bit pointless to me but ok Nov 18 11:25:25 <jwage> could avalanche123 idea work? Nov 18 11:25:34 <avalanche123> at the end of load() method Nov 18 11:26:01 * ornicar (~email@example.com) has left #symfony-dev Nov 18 11:26:05 * ornicar (~firstname.lastname@example.org) has joined #symfony-dev Nov 18 11:26:13 <lsmith> so 5 more mins in this timebox .. or do we move on to the next topic? Nov 18 11:26:15 <avalanche123> https://github.com/fabpot/symfony/blob/master/src/Symfony/Component/DependencyInjection/Extension/Extension.php#L39 Nov 18 11:26:29 <avalanche123> right after the $method is called, n? Nov 18 11:26:32 <avalanche123> *no? Nov 18 11:26:37 <bschussek> as Fabien said, we have agreed on a principle. I suggest to move on Nov 18 11:26:40 <lsmith> ok Nov 18 11:26:43 <fabpot> lsmith: let's move to the next one Nov 18 11:26:49 <lsmith> to next topic .. ornicar plx .. security context serialization between requests: http://bit.ly/aSZSPz Nov 18 11:27:07 <lsmith> or johanness? Nov 18 11:27:19 <ornicar> so right now the user object is serialized Nov 18 11:27:34 <ornicar> to make it persistent Nov 18 11:27:52 <ornicar> when the user object is a doctrine entity or document Nov 18 11:28:21 <ornicar> it makes a problem, because the user object is unserialized and available from the token, but the doctrine entity/document manager is not aware of it Nov 18 11:28:46 <ornicar> I guess we have to find a way to make the object manager aware of it Nov 18 11:28:47 <jmikola|w> ornicar: are you suggesting we instead serialize the recipe to fetch it back from the provider? so at least the provider name and unique value from the user object? Nov 18 11:29:18 * johnkary (~email@example.com) has joined #symfony-dev Nov 18 11:29:21 <ornicar> yes, fetch it for each request sounds good to me Nov 18 11:29:27 <jmikola|w> is the actual managed entity/document serialized presently? Nov 18 11:29:36 <avalanche123> you could also just merge() it to manager Nov 18 11:29:39 <johanness> another thing is that right now the security context is shared among firewalls, if we decide to not-share it, the problem of reloading will become a bit easier Nov 18 11:29:44 * beberlei (~firstname.lastname@example.org) has joined #symfony-dev Nov 18 11:29:50 <Seldaek> what I do is: $this->em->merge($this->session->get('user')) Nov 18 11:29:54 <beberlei> sorry i am late :) Nov 18 11:29:58 <jmikola|w> avalanche123: you'd still need to know if it came from ORM or ODM provider, right? Nov 18 11:30:04 <Seldaek> but imo this should be done by hand whenever you want to actually change/persist the object Nov 18 11:30:15 <ornicar> you have to know what user provider to use Nov 18 11:30:25 <Seldaek> otherwise you force sql queries for nothing at every request, this is highly wasteful Nov 18 11:30:26 <johanness> spring allows to specify from which provider to load the user from specifically, but i don't really see this practically working with a shared security context Nov 18 11:30:47 <beberlei> is it really necessary to merge the user into the context every time? Nov 18 11:30:54 <fabpot> johanness: Spring is less flexible, so it is possible for them, not for us Nov 18 11:30:55 <jmikola|w> jwage/avalanche123 will merge()-ing back into ORM/ODM refresh it from the DB? otherwise we might get stale data in there Nov 18 11:30:57 <ornicar> Seldaek it's not only about modifying the user object. If you create a relation to the user object in another object, the manager needs to know the user object Nov 18 11:31:00 <beberlei> from a security pov i mean Nov 18 11:31:02 <avalanche123> jmikola|w, nope Nov 18 11:31:12 <avalanche123> it will add it to identity map AFAIK Nov 18 11:31:16 <avalanche123> maybe introduce event 'session.load'? Nov 18 11:31:17 <Seldaek> ornicar: yes well, that's what I mean. If you do any kind of write op, you should merge by hand Nov 18 11:31:19 <jmikola|w> so i'd be concerned about merging it and accidentally flushing old data Nov 18 11:31:39 <johanness> fabpot: yeah, what i said, it's not working for us :) but i also see a problem with sharing the security context Nov 18 11:31:44 <Seldaek> ornicar: there could be an automatic mode for people that don't want to care, but it also needs an advanced mode for performance Nov 18 11:31:47 <avalanche123> which could be overloaded from the Doctrine bundle? Nov 18 11:32:00 <avalanche123> to merge entities back to entity manager? Nov 18 11:32:23 * digitarald has quit (Ping timeout: 265 seconds) Nov 18 11:32:36 <jmikola|w> would this be a function of the provider class? if so, that's where EntityUserProvider is Nov 18 11:33:02 * digitarald (~digitaral@88-158-158-106.Asconet.ro) has joined #symfony-dev Nov 18 11:33:22 <johanness> you would still need to know which use rprovider to use Nov 18 11:33:28 <fabpot> jmikola|w: the main problem is to know from which provider the user came from when he was authenticated Nov 18 11:33:29 <jmikola|w> perhaps we could use a designated event, such as security.user.provided Nov 18 11:33:29 <johanness> which isn't so trivial Nov 18 11:33:36 <ornicar> I think fetching the user for every request is better. If the user is modified, we want it to be applied to the token user Nov 18 11:33:39 <jmikola|w> which would receive the user object, whatever was serialized, and the provider code Nov 18 11:33:43 <fabpot> johanness: correct Nov 18 11:33:58 <jmikola|w> db-based providers could then refresh or merge as necessary Nov 18 11:34:06 <ornicar> we could save the provider name in the token? Nov 18 11:34:30 <fabpot> ornicar: probably possible, especially as they have names now IIRC Nov 18 11:34:41 <lsmith> ornicar: well thats an app design decision .. the data of the user is being cached in the session .. then you want to decide if on change you update all existing sessions Nov 18 11:34:43 <jmikola|w> ornicar: it would kind of suck if the provider name changed during deployment (people would get security sessions invalidated) Nov 18 11:34:51 <lsmith> just flag something in memcache to require a re-read Nov 18 11:34:57 <lsmith> or if you always just want to load again Nov 18 11:35:28 <jmikola|w> do apps allow multiple providers? or each firewall has one? Nov 18 11:35:34 <ornicar> yes Nov 18 11:35:39 <johanness> jmikola|w: multiple Nov 18 11:35:44 <jmikola|w> so if provider A doesn't find a user, we try provider B? Nov 18 11:36:01 <ornicar> I think each firewall has only one provider Nov 18 11:36:02 <johanness> thats dangerous, you risk logging in a different user Nov 18 11:36:11 <fabpot> ornicar: nope Nov 18 11:36:44 <jmikola|w> johanness: i agree it's a bit ambiguous, but that's probably a topic for next week, heh Nov 18 11:37:04 <lsmith> btw as fabpot and bschussek have to leave early .. i would like to move to "roadmap for form+admin gen" at 17:40 (CET) aka in 3 mins Nov 18 11:37:09 <johanness> requiring a unique name for the use rprovider and serializing it along with the token would be best, then we can pass all providers to the context listeners which chooses the right one Nov 18 11:37:14 * Skorney has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) Nov 18 11:37:18 <jmikola|w> so barring the possibility of provider names changing, i think saving that name in the session is worth looking into Nov 18 11:37:33 <fabpot> jmikola|w: johanness: I agree Nov 18 11:37:54 <jmikola|w> and a flexible event that DoctrineBundle can use? Nov 18 11:37:56 * mvrhov (~Miha@84-255-244-153.static.t-2.net) has joined #symfony-dev Nov 18 11:37:57 <ornicar> I can work on that and submit a new pull request Nov 18 11:38:48 <lsmith> jmikola|w: provider names changing issues is then something for documentation i guess Nov 18 11:39:03 <lsmith> ok .. so moving to "form + admin gen roadmap" now? Nov 18 11:39:09 <johanness> still the other issue about sharing the security context remains, right now it is shared, and i'm not sure this is a good decision for complex configurations Nov 18 11:39:09 <jmikola|w> i'll follow up with ornicar on that over the week; sure Nov 18 11:39:25 <ornicar> ok Nov 18 11:39:35 <lsmith> johanness: lets get this worked out first Nov 18 11:39:48 <lsmith> bschussek: can you give us some information about the form roadmap Nov 18 11:39:55 <lsmith> and possibily also the admin generator? Nov 18 11:40:14 <bschussek> the roadmap is to finish the form and Validator by the end of the year Nov 18 11:40:27 <bschussek> I cannot work on the admin generator any sooner than that Nov 18 11:40:43 <lsmith> note we talked about the admin generator a bit in the context of the last CMF meeting: https://github.com/symfony-cmf/symfony-cmf/wiki/Post-Symfony-Day-Cologne-2010-Meeting-Notes Nov 18 11:40:57 <lsmith> bschussek and jwage discussed some ideas there Nov 18 11:41:09 <bschussek> the idea was to share code with the CMF project, especially on the UI part Nov 18 11:41:14 <lsmith> bschussek: what are the main issues in the form/validation layer atm? Nov 18 11:41:31 <lsmith> anything you need help with? any major issues people should be aware of? Nov 18 11:41:57 <bschussek> there are a couple of fields and validators that need to be implemented Nov 18 11:42:15 <lsmith> looking at the open tickets: http://trac.symfony-project.org/report/24 Nov 18 11:42:22 <lsmith> many seem to be related to form/validation Nov 18 11:42:23 * vjousse (~email@example.com) has joined #symfony-dev Nov 18 11:42:29 <lsmith> do you need help validating the tickets? Nov 18 11:42:38 <bschussek> lsmith: that would be great Nov 18 11:42:38 <lsmith> maybe some of them are no longer relevant? Nov 18 11:42:40 * digitarald has quit (Quit: digitarald) Nov 18 11:42:44 <Seldaek> bschussek: if you need help with simple stuff like that (implementing new validators..) feel free to shoot me a mail Nov 18 11:42:45 <jmikola|w> bschussek: for fields that might be coupled with JS (i'm thinking of CollectionField), is there any plan for packaging that with symfony? or perhaps the relevant JS would just belong in documentation as an example Nov 18 11:42:46 <bschussek> I did not have time to look through them yet Nov 18 11:42:56 <bschussek> Seldaek: ok Nov 18 11:43:16 <bschussek> jmikola|w: that's the next thing. Many fields are prepared for JS integration, but how we exactly do this needs to be worked out Nov 18 11:43:36 * vjousse has quit (Quit: Quitte) Nov 18 11:43:54 <bschussek> I think we don't need to discuss the JS integration here though, this needs better preparation Nov 18 11:44:02 <Seldaek> yeah having one-size-fits-all js is pretty much impossible Nov 18 11:44:50 <Seldaek> is the plan to ship Sf2 final with an admin generator? Nov 18 11:44:55 <Seldaek> or could that come later? Nov 18 11:44:56 * henrikbjorn has quit (Ping timeout: 245 seconds) Nov 18 11:44:59 <lsmith> one topic that we discussed on the list quite a bit is that the validation happens on the object state and not on the submitted data Nov 18 11:45:07 <pgodel_work> I would like to see it in sf2 final Nov 18 11:45:10 <lsmith> i guess you improved the documentation in this regard lately .. right? Nov 18 11:45:14 <pgodel_work> it is one of the biggest featues of symfony 1 Nov 18 11:45:24 <pgodel_work> and selling points Nov 18 11:45:28 <bschussek> lsmith: I don't think this topic needs more discussion, just more documentation Nov 18 11:45:32 <bschussek> I haven't written that yet Nov 18 11:45:36 <Seldaek> also fabpot if you're here and got a minute to share the current state of things/what's coming next it'd be great Nov 18 11:45:37 <lsmith> k Nov 18 11:45:46 <fabpot> admin gen will be a bundle Nov 18 11:45:48 <lsmith> i also stumbled over the RepeatField: http://trac.symfony-project.org/ticket/9219 Nov 18 11:45:53 <fabpot> like everything else Nov 18 11:46:02 <fabpot> Seldaek: about what? Nov 18 11:46:02 <lsmith> there seems to be a conceptual issue there in relation to validation Nov 18 11:46:09 <Seldaek> fabpot: general Sf2 progress Nov 18 11:46:15 <jmikola|w> Seldaek: i think security was the last big surprise feature :) Nov 18 11:46:25 <Seldaek> fabpot: if you feel like sharing that is :) Nov 18 11:46:33 <fabpot> Seldaek: main features are finished (except perhaps Form/Validator) Nov 18 11:46:34 <beberlei> lsmith: i think having ext/filter (or an equivalent) do filtering on variables based on name / route might be an additional integration, but validation on the object is much better with regards to forms and validating business logic Nov 18 11:46:38 <bschussek> lsmith: I think that's a bug Nov 18 11:46:42 <fabpot> we need more testing now Nov 18 11:47:00 * mvrhov has quit (Read error: Connection reset by peer) Nov 18 11:47:07 <Seldaek> fabpot: ok fair enough :) Nov 18 11:47:17 <fabpot> and things like the admin gen is something we can do without any change to the core framework Nov 18 11:47:23 <Seldaek> I'll try to implement a caching kernel this weekend Nov 18 11:47:26 * mvrhov (~Miha@84-255-244-153.static.t-2.net) has joined #symfony-dev Nov 18 11:47:30 <jmikola|w> fabpot: would a continuous integration server on your fabpot branch be helpful? :) Nov 18 11:47:30 <lsmith> since the security component was committed .. i have seen a steady increase in pull requests .. but also increasingly shorter turn around time by fabpot in getting them in Nov 18 11:47:32 <fabpot> "caching kernel"? Nov 18 11:47:33 * henrikbjorn (~firstname.lastname@example.org) has joined #symfony-dev Nov 18 11:47:35 <lsmith> this is really great .. Nov 18 11:47:47 <Seldaek> fabpot: I mean.. the AppCache thingy, on top of the kernel, I'm tired sorry :) Nov 18 11:47:50 <bschussek> are there anymore questions on forms or validation? Nov 18 11:48:00 <beberlei> bschussek: yes one i have Nov 18 11:48:09 <fabpot> jmikola|w: I have one internally at Sensio Nov 18 11:48:14 <beberlei> the choices validator is rather weak on detecting the available choises Nov 18 11:48:15 * old_sound has quit (Quit: old_sound) Nov 18 11:48:31 <beberlei> say i have an entity with a many to one relation: BlogPost -> Author Nov 18 11:48:35 <johanness> fabpot: is there something coming regaring ACL on domain objects? Nov 18 11:48:37 <beberlei> and my form has a select dropdown Nov 18 11:48:39 <bschussek> beberlei: can you write a bug report? Nov 18 11:48:46 <beberlei> yah probably better Nov 18 11:48:48 <beberlei> or email Nov 18 11:48:51 <Seldaek> jmikola|w: the good ol' Sismo uh.. I hope you have time to make that public one day :) Nov 18 11:48:51 <bschussek> yes, thanks Nov 18 11:49:10 <fabpot> johanness: I have started something for Doctrine, but I did not had time to work on it. If someone want to work on that, that would be great Nov 18 11:49:15 <mvrhov> johanness, https://github.com/IamPersistent/AclBundle not good enough for inclusion? Nov 18 11:49:25 <johanness> fabpot: i can look into it Nov 18 11:49:26 <Seldaek> fabpot: ok that Sismo comment was for you not jmikola|w Nov 18 11:49:28 <lsmith> ok .. in theory we have one more topic that also got 6 votes .. which is flash messages .. but i think i could do a better job preparing that topic Nov 18 11:49:48 <johanness> maybe you can share the code you already have Nov 18 11:49:54 <lsmith> so i would repropose that topic for next week Nov 18 11:50:11 <jmikola|w> lsmith: i18n translation in messages? Nov 18 11:50:14 <lsmith> same as avalanche123's restful view and beberlei doctrine naming assumptions topic Nov 18 11:50:26 <fabpot> johanness: it's just one class that does not even work but send me an email and I will send it to you Nov 18 11:50:30 <avalanche123> yeah, that works Nov 18 11:50:38 <lsmith> jmikola|w: yeah .. the entire work flow for flash messages .. both with and without i18n .. and also how to best display them Nov 18 11:50:50 <lsmith> both in a central place in the layout and specific places in templates Nov 18 11:51:33 <lsmith> so with that .. i am closing todays meeting .. feel free to stay and chat :) Nov 18 11:51:49 <fabpot> thanks all for the nice chat and talk to you next week Nov 18 11:51:58 <henrikbjorn> the log Will go online? Nov 18 11:52:01 * fabpot has quit (Quit: fabpot) Nov 18 11:52:04 <lsmith> henrikbjorn: as always Nov 18 11:52:12 <henrikbjorn> thanks