IRCLogs20101118 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20101118

lsmith (IP:
11/18/10 21:39:11 (7 years ago)



  • IRCLogs20101118

    v0 v1  
     1= Summary = 
     5== Console dependency injection == 
     8== Best practices for dynamic service definitions == 
     11== Security context serialization between requests == 
     14== Current status and roadmap of the form framework and the admin generator == 
     17= IRC logs = 
     19Nov 18 10:58:48 <lsmith>        ok .. i closed the vote 
     20Nov 18 10:59:00 <lsmith>        avalanche123: sure lets go 
     21Nov 18 10:59:08 <avalanche123>  hi everyone! 
     22Nov 18 10:59:19 <avalanche123>  the first topic on the list is the console DIC 
     23Nov 18 10:59:26 <avalanche123>  or rather I think it makes sense 
     24Nov 18 10:59:37 <avalanche123>  to register all console commands as services in DIC 
     25Nov 18 10:59:43 <avalanche123>  for easy testing and mocking 
     26Nov 18 10:59:47 <avalanche123>  more here - 
     27Nov 18 11:00:09 <avalanche123>  the post there includes an example  of rewriting the existing command 
     28Nov 18 11:00:17 <avalanche123>  in DIC compatible way 
     29Nov 18 11:00:23 <avalanche123>  and making it testable 
     30Nov 18 11:00:46 <lsmith>        there is a pull request too 
     31Nov 18 11:00:55 <avalanche123>  lsmith is correct 
     32Nov 18 11:01:11 <avalanche123>  there is a pull request, but it doesn't include the rewriting of existing commands 
     33Nov 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 
     34Nov 18 11:01:31 *       Garfield-fr has quit (Quit:  ⏏) 
     35Nov 18 11:01:41 <avalanche123>  yes, fabpot said, that that would make the container much bigger 
     36Nov 18 11:01:42 <lsmith>        which is a growing concern even before adding this 
     37Nov 18 11:02:00 <lsmith>        are there any other concerns? 
     38Nov 18 11:02:25 <avalanche123>  and I agree, that it would, however, OpenSky's largest DIC is 201,327 bytes 
     39Nov 18 11:02:31 <avalanche123>  which doesn't seem that big 
     40Nov 18 11:02:36 <avalanche123>  and we ahve lots of stuff there too 
     41Nov 18 11:02:40 <avalanche123>  *have 
     42Nov 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?... 
     43Nov 18 11:03:07 <lsmith>        right .. but opensky has taken the "multiple app" approach .. which might be the best practice to handle this concern 
     44Nov 18 11:03:15 <avalanche123>  true 
     45Nov 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 
     46Nov 18 11:03:39 <avalanche123>  yes, I agree, that its sub-optimal 
     47Nov 18 11:03:53 *       bschussek (~bschussek@ has joined #symfony-dev 
     48Nov 18 11:03:56 <avalanche123>  I was thinking about how to split container for quite a bit 
     49Nov 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 
     50Nov 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 
     51Nov 18 11:04:20 <fabpot>        also because then, it can be resued in another context 
     52Nov 18 11:04:21 <lsmith>        but it would mean that the services need to be managed in separate configs 
     53Nov 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 
     54Nov 18 11:05:11 <avalanche123>  I see 
     55Nov 18 11:05:32 <avalanche123>  doctrine commands for example could benefit from that 
     56Nov 18 11:05:39 <fabpot>        lsmith: what do you want to "extend"? 
     57Nov 18 11:05:51 <avalanche123>  since there would not be a need for bundle specific command classes that extend the base ones anymore 
     58Nov 18 11:05:58 <fabpot>        avalanche123: you mean, refactoring code to a "model" 
     59Nov 18 11:06:11 <avalanche123>  not sure 
     60Nov 18 11:06:14 <avalanche123>  what I mean is 
     61Nov 18 11:06:26 <avalanche123>  DIC gives you the benefit of configuration 
     62Nov 18 11:06:33 <avalanche123>  which is not available with convention based 
     63Nov 18 11:06:38 <avalanche123>  command instantiation 
     64Nov 18 11:07:00 <avalanche123>  so doctrine for example needs to create these dummy command classes in their bundles 
     65Nov 18 11:07:13 <avalanche123>  just because there is no way to point to the real ones 
     66Nov 18 11:07:39 <avalanche123>  am I making sense? 
     67Nov 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 
     68Nov 18 11:07:45 <fabpot>        avalanche123: not sure ;) 
     69Nov 18 11:07:49 <avalanche123>  :) 
     70Nov 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 
     71Nov 18 11:08:16 <jwage> has anyone tested or done any benchmarks or anything with a massive DIC? 
     72Nov 18 11:08:24 <avalanche123>  jwage, I think we need to 
     73Nov 18 11:08:32 <avalanche123>  otherwise its just an empty argument 
     74Nov 18 11:08:38 <jwage> I just can't imagine that it really is a problem 
     75Nov 18 11:08:49 <fabpot>        lsmith: but a command is just a way to give your model some input and output something, nothing more 
     76Nov 18 11:08:54 <avalanche123>  OpenSky's DIC is 4500+ loc 
     77Nov 18 11:08:59 <jwage> i think you;d have to have like thousands and thousands of services 
     78Nov 18 11:09:01 <fabpot>        jwage: more code == less speed with PHP 
     79Nov 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 
     80Nov 18 11:09:03 <jwage> which is unrealistic 
     81Nov 18 11:09:28 <jwage> fabpot: i know, technically that is right, but the size to speed loss is so small i bet 
     82Nov 18 11:09:28 <avalanche123>  lsmith, I think I agree 
     83Nov 18 11:09:33 <jwage> with the size of DIC we're dealing with 
     84Nov 18 11:09:38 *       cliassom ( has joined #symfony-dev 
     85Nov 18 11:09:56 <avalanche123>  so maybe we fix the size problem when it really becomes a problem? 
     86Nov 18 11:09:57 <fabpot>        jwage: it's not (and I did some benchmark some months ago) 
     87Nov 18 11:10:06 <jwage> ok 
     88Nov 18 11:10:09 <fabpot>        avalanche123: my point is not just about the size 
     89Nov 18 11:10:18 <jwage> so in opensky then since we have multiple apps this keeps the number of services low 
     90Nov 18 11:10:20 <fabpot>        it's also about "polluting" the web DIC with non-web services 
     91Nov 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 
     92Nov 18 11:10:22 <jwage> b/c we only enable what that app needs 
     93Nov 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 
     94Nov 18 11:10:31 <jwage> instead of having everything in one app and everything always enabled 
     95Nov 18 11:10:35 *       cliassom ( has left #symfony-dev 
     96Nov 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 
     97Nov 18 11:10:53 <bschussek>     fabpot: what about having separate DICs for web and CLI? 
     98Nov 18 11:10:57 <avalanche123>  but you might want to run command from an http app 
     99Nov 18 11:11:06 <avalanche123>  say you have a message queue 
     100Nov 18 11:11:08 <avalanche123>  rabbit 
     101Nov 18 11:11:12 <fabpot>        avalanche123: NO 
     102Nov 18 11:11:17 <avalanche123>  :) 
     103Nov 18 11:11:21 <avalanche123>  ok, point taken 
     104Nov 18 11:11:27 <fabpot>        avalanche123: you would probably reuse the code from your model, not the command itself 
     105Nov 18 11:11:31 <lsmith>        btw .. 4 more minutes in the timebox 
     106Nov 18 11:11:33 <jmikola|w>     or a shared service :) 
     107Nov 18 11:11:57 <avalanche123>  yeah, I concur that is more semantically correct 
     108Nov 18 11:12:04 <fabpot>        bschussek: probably possible 
     109Nov 18 11:12:16 <fabpot>        bschussek: don't know how much complexity it would add though 
     110Nov 18 11:12:23 <jmikola|w>     bschussek: wouldn't the be accomplished by just separate apps for web/cli? 
     111Nov 18 11:12:23 <avalanche123>  still I'd like to test my commands, I don't see how that could be done without DIC 
     112Nov 18 11:12:32 <jmikola|w>     or you wouldn't want to duplicate kernel code 
     113Nov 18 11:12:34 <jwage> fabpot: does spring have a console? 
     114Nov 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) 
     115Nov 18 11:12:57 <fabpot>        avalanche123: to make it clear, I'm not against introducing services for CLI commands 
     116Nov 18 11:13:17 <jmikola|w>     fabpot: practically, the implementation is just loading things tagged as CLI commands, right? 
     117Nov 18 11:13:24 <jmikola|w>     i haven't seen the pull request 
     118Nov 18 11:13:27 <fabpot>        ok, I think I have a solution 
     119Nov 18 11:13:50 *       avalanche123 held his breath 
     120Nov 18 11:13:51 <jwage> could we just have a cli version of the DI? 
     121Nov 18 11:13:55 <fabpot>        as lsmith said, CLI commands are registered in another configuration file 
     122Nov 18 11:14:01 <fabpot>        which is not loaded by the default Kernel 
     123Nov 18 11:14:09 <fabpot>        but only when in console mode 
     124Nov 18 11:14:48 <lsmith>        ok .. sounds like we have a task for someone to take over :) 
     125Nov 18 11:14:54 <jmikola|w>     so this is an additional DI config, sharing the same application config? 
     126Nov 18 11:15:20 <fabpot>        via another registerContainerConfiguration() method registerContainerCliConfiguration() for instance 
     127Nov 18 11:15:22 <jmikola|w>     i assume CLI services would still want the main (i.e. web) di config 
     128Nov 18 11:15:42 <lsmith>        ok .. seems to me like we made progress .. 
     129Nov 18 11:15:48 <lsmith>        time to move to the next topic 
     130Nov 18 11:15:55 <lsmith>        we have a bit of a 4 way tie here 
     131Nov 18 11:15:58 <fabpot>        or we can also have a AppKernel and a AppCliKernel that extends AppKernel and just override the container configuration 
     132Nov 18 11:16:09 <avalanche123>  fabpot I like it 
     133Nov 18 11:16:09 <lsmith>        i propose we go to "Best practices for dynamic service definitions" next 
     134Nov 18 11:16:27 <avalanche123>  lsmith, mind introducing the topic? 
     135Nov 18 11:16:36 <pgodel_work>   I like the AppCliKernel idea 
     136Nov 18 11:16:37 <lsmith>        so the issue here is that for example in DoctrineBundle we have dynamic services 
     137Nov 18 11:16:52 <lsmith>        and right now these services are essentially hardcoded in the extension class 
     138Nov 18 11:16:53 <jmikola|w>     lsmith: is this anything like the dynamic stuff inside security component too? 
     139Nov 18 11:16:54 <jwage> lsmith: i think we need services that are templates 
     140Nov 18 11:16:56 <jwage> tagged as templates 
     141Nov 18 11:16:57 <fabpot>        lsmith: any conclusion before on the first topic? 
     142Nov 18 11:17:02 <jwage> and are never actually generated in the DIC 
     143Nov 18 11:17:10 <jwage> they are only used as a template to clone in the *Extension.php 
     144Nov 18 11:17:21 <jwage> so for example I can have a DI configuration for a Doctrine\DBAL\Connection 
     145Nov 18 11:17:25 <fabpot>        jwage: that's what we have in the security extension 
     146Nov 18 11:17:32 <jwage> and it is used as the base for creating all connections in the *Extension.php 
     147Nov 18 11:17:35 <fabpot>        I have a special security_template.xml config file with templates 
     148Nov 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 
     149Nov 18 11:17:44 <jwage> and we just load it in the *Extension.php ? 
     150Nov 18 11:17:45 <fabpot>        and the services there are removed at the end of the configuration process 
     151Nov 18 11:17:48 <jwage> ah 
     152Nov 18 11:17:49 <jwage> ok 
     153Nov 18 11:17:50 <fabpot>        so they don't end up in your container 
     154Nov 18 11:17:50 <jwage> hmm 
     155Nov 18 11:17:54 <jwage> couldn't we just add a tag? 
     156Nov 18 11:18:04 <jwage> and have it ignore the ones with that certain tag 
     157Nov 18 11:18:11 <jmikola|w>     jwage: 
     158Nov 18 11:18:36 <fabpot>        jwage: that can be a convention you have, sure 
     159Nov 18 11:18:48 <jwage> ya i just dont want each extension to have to manually remove them 
     160Nov 18 11:18:51 <jwage> and reimplement the same thing 
     161Nov 18 11:18:56 <jwage> over and over 
     162Nov 18 11:19:26 <jmikola|w>     so adding some basic helper methods in Symfony\Component\DependencyInjection\Extension\Extension to handle this convention? 
     163Nov 18 11:19:45 <jwage> ya i dont want to have to do this 
     164Nov 18 11:19:45 <jwage> 
     165Nov 18 11:19:47 <jwage> everytime 
     166Nov 18 11:19:56 <jwage> in the configuration i should be able to just tag a service is "template" 
     167Nov 18 11:19:57 <jwage> or something 
     168Nov 18 11:19:58 <lsmith>        jwage: so we add a new attribute "template" ? 
     169Nov 18 11:20:11 <fabpot>        jwage: sure 
     170Nov 18 11:20:12 <jwage> right, and then the builder won't generate those services 
     171Nov 18 11:20:13 <Seldaek>       why not do this in the Container Dumper ? 
     172Nov 18 11:20:13 <lsmith>        and those are never written in the phpDumper 
     173Nov 18 11:20:20 <jwage> Seldaek: thats what we're suggesting 
     174Nov 18 11:20:26 <jwage> instead of each extension having to reimplement the same removing code 
     175Nov 18 11:20:36 <lsmith>        ok sounds like a plan 
     176Nov 18 11:20:37 <Seldaek>       well, yeah, but suggestions sounded more like helper code in DI Extension 
     177Nov 18 11:20:40 <fabpot>        jwage: no, we are suggesting to do that in the Extension, not in the Dumper 
     178Nov 18 11:20:45 <jwage> hmm 
     179Nov 18 11:20:53 <Seldaek>       so I'd like to clarify the suggestion :) 
     180Nov 18 11:21:06 <jmikola|w>     lsmith: would that possibly ruin the convention that loaders and dumpers won't change things? 
     181Nov 18 11:21:08 <jwage> this just seems weird 
     182Nov 18 11:21:09 <jwage> 
     183Nov 18 11:21:18 <jwage> why not just get the tagged templates and remove them before dumping? 
     184Nov 18 11:21:36 <lsmith>        hmm i guess because then you could indeed have a different behavior 
     185Nov 18 11:21:44 <fabpot>        jmikola|w: exactly. Dumpers just, well, dump the container 
     186Nov 18 11:21:49 <lsmith>        i guess atm in the first request it doesnt actually use the dumper 
     187Nov 18 11:21:50 <jwage> ok 
     188Nov 18 11:22:00 <johanness>     you could also load the templates into a different container builder and clone them from there 
     189Nov 18 11:22:01 <jmikola|w>     fabpot: does DIC generation just use phpdumper at the moment? 
     190Nov 18 11:22:01 <avalanche123>  I think that is what will happen, just the "remove before dumping" takes place in Extension 
     191Nov 18 11:22:07 <johanness>     instead of loading them into the actual container 
     192Nov 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? 
     193Nov 18 11:22:46 *       maerlyn has quit (Quit: Leaving) 
     194Nov 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 
     195Nov 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 
     196Nov 18 11:23:04 <jwage> and they end up using templates and having the services in the DI 
     197Nov 18 11:23:12 <fabpot>        jwage: no, we will provide a special tag and the method to remove them 
     198Nov 18 11:23:15 <jwage> ok 
     199Nov 18 11:23:16 <lsmith>        fabpot: k 
     200Nov 18 11:23:19 <jwage> that works for me then 
     201Nov 18 11:23:22 <Seldaek>       but why provide a method to remove them 
     202Nov 18 11:23:27 <Seldaek>       why not just make it automatically 
     203Nov 18 11:23:33 <Seldaek>       after calling the extensions 
     204Nov 18 11:23:33 <jwage> i just dont wanna have to to the $servicesToRemove = array(); foreach ($servicesToRemove 
     205Nov 18 11:23:34 <jwage> etc 
     206Nov 18 11:23:34 <fabpot>        Seldaek: being explicit 
     207Nov 18 11:23:42 <Seldaek>       well, it's explicitly tagged 
     208Nov 18 11:23:55 <bschussek>     I agree with Seldaek 
     209Nov 18 11:23:56 <jwage> im not sure i see any reason not to remove it automatically 
     210Nov 18 11:24:05 <jwage> if its tagged as template, u dont want it as a real service 
     211Nov 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 
     212Nov 18 11:24:15 <fabpot>        Seldaek: bschussek: jwage: I don't see where we will be able to do that automatically 
     213Nov 18 11:24:29 <jmikola|w>     jwage: the logic for that shouldn't be in a dumper though 
     214Nov 18 11:24:32 <Seldaek>       so either you do it all at the end, or you have to specify 
     215Nov 18 11:24:34 *       wissl ( has joined #symfony-dev 
     216Nov 18 11:24:39 <fabpot>        ok, I think we have a solution. Someone needs to work on an implementation now 
     217Nov 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 
     218Nov 18 11:24:59 <lsmith>        yeah .. i think we have agreed on the principle 
     219Nov 18 11:25:09 <avalanche123>  that could be implemented in the base Extension class 
     220Nov 18 11:25:13 <lsmith>        the rest is detail .. which can still be discussed in the pull request 
     221Nov 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 
     222Nov 18 11:25:25 <jwage> could avalanche123 idea work? 
     223Nov 18 11:25:34 <avalanche123>  at the end of load() method 
     224Nov 18 11:26:01 *       ornicar ( has left #symfony-dev 
     225Nov 18 11:26:05 *       ornicar ( has joined #symfony-dev 
     226Nov 18 11:26:13 <lsmith>        so 5 more mins in this timebox .. or do we move on to the next topic? 
     227Nov 18 11:26:15 <avalanche123> 
     228Nov 18 11:26:29 <avalanche123>  right after the $method is called, n? 
     229Nov 18 11:26:32 <avalanche123>  *no? 
     230Nov 18 11:26:37 <bschussek>     as Fabien said, we have agreed on a principle. I suggest to move on 
     231Nov 18 11:26:40 <lsmith>        ok 
     232Nov 18 11:26:43 <fabpot>        lsmith: let's move to the next one 
     235Nov 18 11:26:49 <lsmith>        to next topic .. ornicar plx .. security context serialization between requests: 
     236Nov 18 11:27:07 <lsmith>        or johanness? 
     237Nov 18 11:27:19 <ornicar>       so right now the user object is serialized 
     238Nov 18 11:27:34 <ornicar>       to make it persistent 
     239Nov 18 11:27:52 <ornicar>       when the user object is a doctrine entity or document 
     240Nov 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 
     241Nov 18 11:28:46 <ornicar>       I guess we have to find a way to make the object manager aware of it 
     242Nov 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? 
     243Nov 18 11:29:18 *       johnkary ( has joined #symfony-dev 
     244Nov 18 11:29:21 <ornicar>       yes, fetch it for each request sounds good to me 
     245Nov 18 11:29:27 <jmikola|w>     is the actual managed entity/document serialized presently? 
     246Nov 18 11:29:36 <avalanche123>  you could also just merge() it to manager 
     247Nov 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 
     248Nov 18 11:29:44 *       beberlei ( has joined #symfony-dev 
     249Nov 18 11:29:50 <Seldaek>       what I do is: $this->em->merge($this->session->get('user')) 
     250Nov 18 11:29:54 <beberlei>      sorry i am late :) 
     251Nov 18 11:29:58 <jmikola|w>     avalanche123: you'd still need to know if it came from ORM or ODM provider, right? 
     252Nov 18 11:30:04 <Seldaek>       but imo this should be done by hand whenever you want to actually change/persist the object 
     253Nov 18 11:30:15 <ornicar>       you have to know what user provider to use 
     254Nov 18 11:30:25 <Seldaek>       otherwise you force sql queries for nothing at every request, this is highly wasteful 
     255Nov 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 
     256Nov 18 11:30:47 <beberlei>      is it really necessary to merge the user into the context every time? 
     257Nov 18 11:30:54 <fabpot>        johanness: Spring is less flexible, so it is possible for them, not for us 
     258Nov 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 
     259Nov 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 
     260Nov 18 11:31:00 <beberlei>      from a security pov i mean 
     261Nov 18 11:31:02 <avalanche123>  jmikola|w, nope 
     262Nov 18 11:31:12 <avalanche123>  it will add it to identity map AFAIK 
     263Nov 18 11:31:16 <avalanche123>  maybe introduce event 'session.load'? 
     264Nov 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 
     265Nov 18 11:31:19 <jmikola|w>     so i'd be concerned about merging it and accidentally flushing old data 
     266Nov 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 
     267Nov 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 
     268Nov 18 11:31:47 <avalanche123>  which could be overloaded from the Doctrine bundle? 
     269Nov 18 11:32:00 <avalanche123>  to merge entities back to entity manager? 
     270Nov 18 11:32:23 *       digitarald has quit (Ping timeout: 265 seconds) 
     271Nov 18 11:32:36 <jmikola|w>     would this be a function of the provider class? if so, that's where EntityUserProvider is 
     272Nov 18 11:33:02 *       digitarald ( has joined #symfony-dev 
     273Nov 18 11:33:22 <johanness>     you would still need to know which use rprovider to use 
     274Nov 18 11:33:28 <fabpot>        jmikola|w: the main problem is to know from which provider the user came from when he was authenticated 
     275Nov 18 11:33:29 <jmikola|w>     perhaps we could use a designated event, such as security.user.provided 
     276Nov 18 11:33:29 <johanness>     which isn't so trivial 
     277Nov 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 
     278Nov 18 11:33:39 <jmikola|w>     which would receive the user object, whatever was serialized, and the provider code 
     279Nov 18 11:33:43 <fabpot>        johanness: correct 
     280Nov 18 11:33:58 <jmikola|w>     db-based providers could then refresh or merge as necessary 
     281Nov 18 11:34:06 <ornicar>       we could save the provider name in the token? 
     282Nov 18 11:34:30 <fabpot>        ornicar: probably possible, especially as they have names now IIRC 
     283Nov 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 
     284Nov 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) 
     285Nov 18 11:34:51 <lsmith>        just flag something in memcache to require a re-read 
     286Nov 18 11:34:57 <lsmith>        or if you always just want to load again 
     287Nov 18 11:35:28 <jmikola|w>     do apps allow multiple providers? or each firewall has one? 
     288Nov 18 11:35:34 <ornicar>       yes 
     289Nov 18 11:35:39 <johanness>     jmikola|w: multiple 
     290Nov 18 11:35:44 <jmikola|w>     so if provider A doesn't find a user, we try provider B? 
     291Nov 18 11:36:01 <ornicar>       I think each firewall has only one provider 
     292Nov 18 11:36:02 <johanness>     thats dangerous, you risk logging in a different user 
     293Nov 18 11:36:11 <fabpot>        ornicar: nope 
     294Nov 18 11:36:44 <jmikola|w>     johanness: i agree it's a bit ambiguous, but that's probably a topic for next week, heh 
     295Nov 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 
     296Nov 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 
     297Nov 18 11:37:14 *       Skorney has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 
     298Nov 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 
     299Nov 18 11:37:33 <fabpot>        jmikola|w: johanness: I agree 
     300Nov 18 11:37:54 <jmikola|w>     and a flexible event that DoctrineBundle can use? 
     301Nov 18 11:37:56 *       mvrhov ( has joined #symfony-dev 
     302Nov 18 11:37:57 <ornicar>       I can work on that and submit a new pull request 
     303Nov 18 11:38:48 <lsmith>        jmikola|w: provider names changing issues is then something for documentation i guess 
     304Nov 18 11:39:03 <lsmith>        ok .. so moving to "form + admin gen roadmap" now? 
     305Nov 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 
     306Nov 18 11:39:09 <jmikola|w>     i'll follow up with ornicar on that over the week; sure 
     307Nov 18 11:39:25 <ornicar>       ok 
     308Nov 18 11:39:35 <lsmith>        johanness: lets get this worked out first 
     309Nov 18 11:39:48 <lsmith>        bschussek: can you give us some information about the form roadmap 
     310Nov 18 11:39:55 <lsmith>        and possibily also the admin generator? 
     311Nov 18 11:40:14 <bschussek>     the roadmap is to finish the form and Validator by the end of the year 
     312Nov 18 11:40:27 <bschussek>     I cannot work on the admin generator any sooner than that 
     313Nov 18 11:40:43 <lsmith>        note we talked about the admin generator a bit in the context of the last CMF meeting: 
     314Nov 18 11:40:57 <lsmith>        bschussek and jwage discussed some ideas there 
     315Nov 18 11:41:09 <bschussek>     the idea was to share code with the CMF project, especially on the UI part 
     316Nov 18 11:41:14 <lsmith>        bschussek: what are the main issues in the form/validation layer atm? 
     317Nov 18 11:41:31 <lsmith>        anything you need help with? any major issues people should be aware of? 
     318Nov 18 11:41:57 <bschussek>     there are a couple of fields and validators that need to be implemented 
     319Nov 18 11:42:15 <lsmith>        looking at the open tickets: 
     320Nov 18 11:42:22 <lsmith>        many seem to be related to form/validation 
     321Nov 18 11:42:23 *       vjousse (~vjousse@ has joined #symfony-dev 
     322Nov 18 11:42:29 <lsmith>        do you need help validating the tickets? 
     323Nov 18 11:42:38 <bschussek>     lsmith: that would be great 
     324Nov 18 11:42:38 <lsmith>        maybe some of them are no longer relevant? 
     325Nov 18 11:42:40 *       digitarald has quit (Quit: digitarald) 
     326Nov 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 
     327Nov 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 
     328Nov 18 11:42:46 <bschussek>     I did not have time to look through them yet 
     329Nov 18 11:42:56 <bschussek>     Seldaek: ok 
     330Nov 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 
     331Nov 18 11:43:36 *       vjousse has quit (Quit: Quitte) 
     332Nov 18 11:43:54 <bschussek>     I think we don't need to discuss the JS integration here though, this needs better preparation 
     333Nov 18 11:44:02 <Seldaek>       yeah having one-size-fits-all js is pretty much impossible 
     334Nov 18 11:44:50 <Seldaek>       is the plan to ship Sf2 final with an admin generator? 
     335Nov 18 11:44:55 <Seldaek>       or could that come later? 
     336Nov 18 11:44:56 *       henrikbjorn has quit (Ping timeout: 245 seconds) 
     337Nov 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 
     338Nov 18 11:45:07 <pgodel_work>   I would like to see it in sf2 final 
     339Nov 18 11:45:10 <lsmith>        i guess you improved the documentation in this regard lately .. right? 
     340Nov 18 11:45:14 <pgodel_work>   it is one of the biggest featues of symfony 1 
     341Nov 18 11:45:24 <pgodel_work>   and selling points 
     342Nov 18 11:45:28 <bschussek>     lsmith: I don't think this topic needs more discussion, just more documentation 
     343Nov 18 11:45:32 <bschussek>     I haven't written that yet 
     344Nov 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 
     345Nov 18 11:45:37 <lsmith>        k 
     346Nov 18 11:45:46 <fabpot>        admin gen will be a bundle 
     347Nov 18 11:45:48 <lsmith>        i also stumbled over the RepeatField: 
     348Nov 18 11:45:53 <fabpot>        like everything else 
     349Nov 18 11:46:02 <fabpot>        Seldaek: about what? 
     350Nov 18 11:46:02 <lsmith>        there seems to be a conceptual issue there in relation to validation 
     351Nov 18 11:46:09 <Seldaek>       fabpot: general Sf2 progress 
     352Nov 18 11:46:15 <jmikola|w>     Seldaek: i think security was the last big surprise feature :) 
     353Nov 18 11:46:25 <Seldaek>       fabpot: if you feel like sharing that is :) 
     354Nov 18 11:46:33 <fabpot>        Seldaek: main features are finished (except perhaps Form/Validator) 
     355Nov 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 
     356Nov 18 11:46:38 <bschussek>     lsmith: I think that's a bug 
     357Nov 18 11:46:42 <fabpot>        we need more testing now 
     358Nov 18 11:47:00 *       mvrhov has quit (Read error: Connection reset by peer) 
     359Nov 18 11:47:07 <Seldaek>       fabpot: ok fair enough :) 
     360Nov 18 11:47:17 <fabpot>        and things like the admin gen is something we can do without any change to the core framework 
     361Nov 18 11:47:23 <Seldaek>       I'll try to implement a caching kernel this weekend 
     362Nov 18 11:47:26 *       mvrhov ( has joined #symfony-dev 
     363Nov 18 11:47:30 <jmikola|w>     fabpot: would a continuous integration server on your fabpot branch be helpful? :) 
     364Nov 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 
     365Nov 18 11:47:32 <fabpot>        "caching kernel"? 
     366Nov 18 11:47:33 *       henrikbjorn ( has joined #symfony-dev 
     367Nov 18 11:47:35 <lsmith>        this is really great .. 
     368Nov 18 11:47:47 <Seldaek>       fabpot: I mean.. the AppCache thingy, on top of the kernel, I'm tired sorry :) 
     369Nov 18 11:47:50 <bschussek>     are there anymore questions on forms or validation? 
     370Nov 18 11:48:00 <beberlei>      bschussek: yes one i have 
     371Nov 18 11:48:09 <fabpot>        jmikola|w: I have one internally at Sensio 
     372Nov 18 11:48:14 <beberlei>      the choices validator is rather weak on detecting the available choises 
     373Nov 18 11:48:15 *       old_sound has quit (Quit: old_sound) 
     374Nov 18 11:48:31 <beberlei>      say i have an entity with a many to one relation: BlogPost -> Author 
     375Nov 18 11:48:35 <johanness>     fabpot: is there something coming regaring ACL on domain objects? 
     376Nov 18 11:48:37 <beberlei>      and my form has a select dropdown 
     377Nov 18 11:48:39 <bschussek>     beberlei: can you write a bug report? 
     378Nov 18 11:48:46 <beberlei>      yah probably better 
     379Nov 18 11:48:48 <beberlei>      or email 
     380Nov 18 11:48:51 <Seldaek>       jmikola|w: the good ol' Sismo uh.. I hope you have time to make that public one day :) 
     381Nov 18 11:48:51 <bschussek>     yes, thanks 
     382Nov 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 
     383Nov 18 11:49:15 <mvrhov>        johanness, not good enough for inclusion? 
     384Nov 18 11:49:25 <johanness>     fabpot: i can look into it 
     385Nov 18 11:49:26 <Seldaek>       fabpot: ok that Sismo comment was for you not jmikola|w 
     386Nov 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 
     387Nov 18 11:49:48 <johanness>     maybe you can share the code you already have 
     388Nov 18 11:49:54 <lsmith>        so i would repropose that topic for next week 
     389Nov 18 11:50:11 <jmikola|w>     lsmith: i18n translation in messages? 
     390Nov 18 11:50:14 <lsmith>        same as avalanche123's restful view and beberlei doctrine naming assumptions topic 
     391Nov 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 
     392Nov 18 11:50:30 <avalanche123>  yeah, that works 
     393Nov 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 
     394Nov 18 11:50:50 <lsmith>        both in a central place in the layout and specific places in templates 
     395Nov 18 11:51:33 <lsmith>        so with that .. i am closing todays meeting .. feel free to stay and chat :) 
     396Nov 18 11:51:49 <fabpot>        thanks all for the nice chat and talk to you next week 
     397Nov 18 11:51:58 <henrikbjorn>   the log Will go online? 
     398Nov 18 11:52:01 *       fabpot has quit (Quit: fabpot) 
     399Nov 18 11:52:04 <lsmith>        henrikbjorn: as always 
     400Nov 18 11:52:12 <henrikbjorn>   thanks