IRCLogs20110113 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110113

lsmith (IP:
01/13/11 18:04:35 (7 years ago)



  • IRCLogs20110113

    v0 v1  
     1= Summary = 
     5== Roadmap until stable release ==                
     9== credentials serialized in clear text ==                
     13== Suggested changes to default rendering of forms ==             
     17== RFC for DIC template syntax == 
     21== Design questions about the routing and security model == 
     25= IRC logs = 
     27Jan 13 10:59:42 <lsmith>        fabpot: ping 
     28Jan 13 11:00:09 <lsmith>        first topic would be you -> Roadmap until Symfony2 stable release 
     29Jan 13 11:00:35 <lsmith>        johanness: ping 
     30Jan 13 11:00:46 <johanness>     yeah? 
     31Jan 13 11:00:50 <johanness>     can't comment on this :) 
     32Jan 13 11:01:07 <fabpot>        ok 
     33Jan 13 11:01:21 <fabpot>        we need to stabilize the Symfony2 API 
     34Jan 13 11:01:39 <fabpot>        like it or not, but like I said last week, we need to try to release Symfony2 final March 6th 
     35Jan 13 11:01:44 <fabpot>        which is in less than 2 months! 
     36Jan 13 11:02:06 <fabpot>        so, I propose to have some main topics for each week until the first RC to stabilize the API 
     37Jan 13 11:02:23 <fabpot>        to have a good base, I will release a PR tomorrow with a sandbox 
     38Jan 13 11:02:31 <fabpot>        February 5- 
     39Jan 13 11:02:42 <fabpot>        and 6, we will have 2 hacking days 
     40Jan 13 11:02:58 <fabpot>        February 6th: the release of the first Symfony2 RC 
     41Jan 13 11:03:10 <fabpot>        another hacking day March 5th 
     42Jan 13 11:03:23 <fabpot>        the hacking days will take place in SF and Paris, but also online of course 
     43Jan 13 11:03:26 <lsmith>        i guess we can try to incorporate people virtually to those hackdays 
     44Jan 13 11:04:02 <fabpot>        So, instead of working on everything, I want to have some guidelines so that many people can help us 
     45Jan 13 11:04:11 <lsmith>        i guess at the hackdays one big area that people can "easily" get involved in is expanding the testing 
     46Jan 13 11:04:13 <pgodel_work>   are you going to propose topics for the hacking days, is there going to be an agenda ? 
     47Jan 13 11:04:39 <lsmith>        we will just need to organize things a bit to prevent redundant efforts 
     48Jan 13 11:04:40 <fabpot>        after some talks with Johannes, Bernhard, Jonathan, and Benjamin, here is a tentative schedule 
     49Jan 13 11:04:58 <fabpot>        oh, before that 
     50Jan 13 11:05:14 <fabpot>        I think we have 3 main big components that requires special attention 
     51Jan 13 11:05:18 <fabpot>        Form/Validator/Locale 
     52Jan 13 11:05:22 <fabpot>        Doctrine*Bundle 
     53Jan 13 11:05:24 <fabpot>        Security 
     54Jan 13 11:05:58 <lsmith>        in security i assume you are including ACL 
     55Jan 13 11:06:03 <fabpot>        lsmith: yes 
     56Jan 13 11:06:12 *       rouffj_ ( has joined #symfony-dev 
     57Jan 13 11:06:15 *       aramirez ( has joined #symfony-dev 
     58Jan 13 11:06:29 <fabpot>        so, next week for instance, we will focus our tests and work on the Security component 
     59Jan 13 11:06:30 <lsmith>        Form/Validator/Locale you mean removing the intl dependency? 
     60Jan 13 11:06:44 <fabpot>        lsmith: I mean everything related to these 3 components 
     61Jan 13 11:06:49 <lsmith>        k 
     62Jan 13 11:06:50 <fabpot>        removing the intl dependency is just one thing 
     63Jan 13 11:07:07 <fabpot>        the week after, Form/Validator/Locale 
     64Jan 13 11:07:09 <pgodel_work>   that may be the biggest of all 3 
     65Jan 13 11:07:16 <fabpot>        and then the Doctrine bundles 
     66Jan 13 11:07:55 <Seldaek>       I'd love it if we could remove intl altogether, I don't like it, but I'm not sure what other options are there besides ZF stuff 
     67Jan 13 11:07:56 <fabpot>        So, I will write a post for the Symfony blog, and I want t opublish it tomorrow with the new Preview Release 
     68Jan 13 11:08:19 <fabpot>        Seldaek: my point of view is that we cannot have a hard dependency with intl 
     69Jan 13 11:08:28 <fabpot>        forms should work without the intl extension 
     70Jan 13 11:08:35 <lsmith>        fabpot: how do we track the open issues and responsibilities? 
     71Jan 13 11:08:37 <fabpot>        in which case, you will loose some abilities of course 
     72Jan 13 11:08:38 <Seldaek>       yeah, obviously.. but we need to see what is working and what is not if intl is missing 
     73Jan 13 11:08:58 <fabpot>        In my post, I will name the people in charge of each main components 
     74Jan 13 11:09:04 <fabpot>        So, for forms, it's Bernhard 
     75Jan 13 11:09:04 <lsmith>        also we need to push towards closing tickets on 
     76Jan 13 11:09:11 <fabpot>        for Doctrine, Jonathan and Benjamin 
     77Jan 13 11:09:17 <fabpot>        for Security, Johannes and myself 
     78Jan 13 11:09:45 <lsmith>        fabpot: yeah ... but how do we know what to work on specifically? how to we prevent duplicate efforts? 
     79Jan 13 11:10:05 <fabpot>        lsmith: the goal is to test the components on real-life situations 
     80Jan 13 11:10:07 <fabpot>        to add unit tests 
     81Jan 13 11:10:10 <fabpot>        to validate the API 
     82Jan 13 11:10:21 <fabpot>        and to finish major missing features 
     83Jan 13 11:10:37 <fabpot>        I think validating the API is the biggest work 
     84Jan 13 11:10:51 <fabpot>        fixing bugs can be done after RC, changing the API won't be an option 
     85Jan 13 11:11:05 <Seldaek>       fabpot: also, can you make sure bernhard is really available the week of the form stuff, because he tends to be hard to reach and he is a single point of failure for Forms questions 
     86Jan 13 11:11:12 <lsmith>        right .. for the later .. for security i see: rememberme, cleartext password in session, adding csrf to form login as open issues for example 
     87Jan 13 11:11:37 <lsmith>        Seldaek: well in that week .. he will actually be in the liip offices :) 
     88Jan 13 11:11:43 <Seldaek>       ok goody 
     89Jan 13 11:12:12 <fabpot>        Seldaek: well, Sensio supports his work on the form framework, that's all I can do 
     90Jan 13 11:12:21 <fabpot>        I think he has other things to do as well 
     91Jan 13 11:12:36 <Seldaek>       fabpot: yeah no worry, but if he's in the liip office then you can put me as secondary contact, I'll make sure he answers :P 
     92Jan 13 11:12:48 <fabpot>        that's great! 
     93Jan 13 11:13:32 <Seldaek>       next? 
     94Jan 13 11:13:36 <lsmith>        anything else? ah i will go through meeting summaries .. looking for decisions taken .. that havent been implemented yet 
     95Jan 13 11:13:49 <Seldaek>       yeah that'd be great 
     96Jan 13 11:13:58 <fabpot>        perhaps one last thing 
     97Jan 13 11:13:59 <lsmith>        reminding people that promised to work on stuff 
     98Jan 13 11:14:04 <fabpot>        so that it's clear for everybody 
     99Jan 13 11:14:06 <Seldaek>       watching for topics on the ml that have had no answers might be good too, but takes time 
     100Jan 13 11:14:13 <fabpot>        after RC1, we will need to keep BC 
     101Jan 13 11:14:50 <avalanche123>  I think that Request object needs to be revisited too 
     102Jan 13 11:14:51 <fabpot>        so, if you think that some APIs are broken, you still have 3 weeks 
     103Jan 13 11:14:55 <avalanche123>  I have a couple of ideas 
     104Jan 13 11:14:58 <avalanche123>  will email 
     105Jan 13 11:14:59 <fabpot>        avalanche123: agree 
     106Jan 13 11:15:00 *       rooster hates that he has to leave - but will catch up with the summary later... 
     107Jan 13 11:15:00 <lsmith>        someone should also setup PHP_CodeSniffer checking .. stuff like phpdoc and CS stuff 
     108Jan 13 11:15:04 <avalanche123>  been very busy recently 
     109Jan 13 11:15:10 <lsmith>        another area where people can easily help on the hackdays 
     110Jan 13 11:15:32 <pgodel_work>   lsmith: good idea 
     111Jan 13 11:15:35 <Seldaek>       lsmith: that's easy to fix later though 
     112Jan 13 11:15:47 <avalanche123> 
     113Jan 13 11:15:47 <Seldaek>       let's break all the BC we can in the next 3 weeks :) 
     114Jan 13 11:15:48 <lsmith>        Seldaek: of course .. but later isnt that much longer :) 
     115Jan 13 11:16:06 *       rooster has quit (Read error: Connection reset by peer) 
     116Jan 13 11:16:08 <lsmith>        ok .. moving on? 
     117Jan 13 11:16:25 <lsmith>        credentials serialized in clear text: 
     118Jan 13 11:16:38 <lsmith>        i noticed that the session file's contain the clear text password 
     119Jan 13 11:16:47 <lsmith>        even if password hashing is enabled 
     120Jan 13 11:17:03 <Seldaek>       yeah that sounds unacceptable 
     121Jan 13 11:17:08 <lsmith>        is there a reason for this? and if so .. we need to remove it :) 
     122Jan 13 11:17:17 <jmikola|w>     shouldn't eraseCredentials() be stripping that out? 
     123Jan 13 11:17:34 <fabpot>        sound like a bug 
     124Jan 13 11:17:36 <johanness>     it's not a major issue, and spring actually introduced erasing credentials only fairly recently 
     125Jan 13 11:17:36 <fabpot>        sounds* 
     126Jan 13 11:17:36 <Seldaek>       yeah but the passwords shouldn't be stored on the user object either 
     127Jan 13 11:17:37 *       rande has quit (Read error: Connection reset by peer) 
     128Jan 13 11:17:48 <johanness>     my pull request with the shared authentication manager fixes this as well 
     129Jan 13 11:17:51 <Seldaek>       they should be hashed ASAP and forgotten 
     130Jan 13 11:18:07 <avalanche123>  Seldaek +1 
     131Jan 13 11:18:31 <Seldaek>       otherwise it's just a disaster waiting to happen, especially if it depends on users writing some function to clean up sensitive data 
     132Jan 13 11:18:51 <lsmith>        fabpot: when i checked .. the code seemed to rely on being able to rehash the password during subsequent requests after login .. 
     133Jan 13 11:19:19 <lsmith>        ok .. then i will just note down that this issue needs to be addressed and is not something we will accept .. 
     134Jan 13 11:19:36 <lsmith>        so i guess we can move to the next topic 
     135Jan 13 11:19:45 <lsmith>        Suggested changes to default rendering of forms: 
     136Jan 13 11:19:49 <lsmith>        tom doesnt seem to be around .. 
     137Jan 13 11:20:16 <lsmith>        from my understanding he was suggesting to make the out of the box form's more "useful" 
     138Jan 13 11:20:35 <lsmith>        while fabien made it clear that its easy to selectively override the defaults via the form theming 
     139Jan 13 11:20:49 <pgodel_work>   checking if Tom can login 
     140Jan 13 11:20:50 <lsmith>        maybe one of the people who voted on this topic has something to say? 
     141Jan 13 11:21:07 <lsmith>        weaverryan, avalanche123, pgodel_work? 
     142Jan 13 11:21:15 <weaverryan>    lsmith: yea, just getting here 
     143Jan 13 11:21:18 <jmikola|w>     i thought the sf_ prefixes would be ripe for an admin generator bundle, that would likely provide base CSS as well 
     144Jan 13 11:21:21 <fabpot>        I think that it makes sense to have something that can describe the layout of a form, but that's different from the default form template 
     145Jan 13 11:21:29 <weaverryan>    we may need to shelf it - I haven't had enough time to study it, but I'm studying it now 
     146Jan 13 11:21:50 *       Dominique__ ( has joined #symfony-dev 
     147Jan 13 11:21:59 <avalanche123>  well, I though just ading classes and ids to default form rendering should work 
     148Jan 13 11:22:07 <avalanche123>  not in the field rendering functions though 
     149Jan 13 11:22:14 <avalanche123>  but onle when they render the whole form 
     150Jan 13 11:22:20 <avalanche123>  *only 
     151Jan 13 11:22:24 <jmikola|w>     i don't see the benefit of adding class names unless sf2 was going to ship with some default CSS 
     152Jan 13 11:22:30 <pgodel_work>   I agree in general with Tom that some form of default classes would help a lot, and as long it can be changed it should not hurt at all 
     153Jan 13 11:22:35 <jmikola|w>     otherwise, that's added documentation just to tell the user what elements to style themselves 
     154Jan 13 11:22:59 <avalanche123>  jmikola|w, like I said, only if they use form_render(form) 
     155Jan 13 11:23:00 <fabpot>        avalanche123: the problem is that if we start adding classes and ids, people will want to keep that and will ask for more flexibility 
     156Jan 13 11:23:14 <fabpot>        like being able to put fields side by side instead of one after the other, ... 
     157Jan 13 11:23:18 <avalanche123>  fabpot I see your point 
     158Jan 13 11:23:19 <lsmith>        jmikola|w: well there is now a bit of a chance that for the stable release there will be an admin generator bundle 
     159Jan 13 11:23:26 <Seldaek>       jmikola|w: default class names, if they're not sf_ prefixed, could be useful imo, makes it easier to hook your css into it without the need for custom form templates. But then again, I haven't needed to modify form templates yet.. 
     160Jan 13 11:23:34 <Seldaek>       usually a class on the form element itself is enough 
     161Jan 13 11:23:34 <jmikola|w>     tom's suggestion about not having naked text nodes made sense though... at the very least we can add <span>'s 
     162Jan 13 11:23:35 <pgodel_work>   fabpot: but don't you think this is repeating work that needs to be done most of the time you are dealing with forms ? 
     163Jan 13 11:23:53 <avalanche123>  I think its not necessary to make it part of the framework 
     164Jan 13 11:23:53 <lsmith>        thomas and bernhard will be collaborating to push forward 
     165Jan 13 11:24:00 *       boutell ( has joined #symfony-dev 
     166Jan 13 11:24:02 <Seldaek>       jmikola|w: no that's insane, wrap the entire selects into a <p> or whatever, but not a comma wrapped in a <span>.. :) 
     167Jan 13 11:24:13 <fabpot>        pgodel_work: when was the last time you used that to output a form? my answer is never 
     168Jan 13 11:24:18 <avalanche123>  we could make it a LazyFormsBundle 
     169Jan 13 11:24:19 <boutell>       Hey, the troublemaker who wrote that post to symfony-devs is here (: 
     170Jan 13 11:24:36 <Herzult>       I think a good documentation on how create a custom theme is sufficient 
     171Jan 13 11:24:58 <Seldaek>       Herzult: yeah, I'd tend to agree 
     172Jan 13 11:25:03 <avalanche123>  Herzult +1 
     173Jan 13 11:25:08 <avalanche123>  fabpot I concur:) 
     174Jan 13 11:25:26 <Seldaek>       with one class on the <form> tag, you don't really need classes all over the place inside 
     175Jan 13 11:25:31 <Seldaek>       there are tag names and attributes already 
     176Jan 13 11:25:32 <lsmith>        right .. there will likely be form theme bundles 
     177Jan 13 11:25:39 <weaverryan>    I haven't looked into the forms yet, so as long as it's the "pluggable" so that I can easily share my themes, etc 
     178Jan 13 11:25:45 <boutell>       Seldaek: that's not sufficient to target most things. 
     179Jan 13 11:25:48 <boutell>       are there any front end devs here 
     180Jan 13 11:25:55 <boutell>       or is this a bunch of back end PHP guys arguing about what front end devs want 
     181Jan 13 11:25:59 <Seldaek>       boutell: well I haven't had any problems so far styling stuff 
     182Jan 13 11:26:12 <fabpot>        boutell: my point is not to say that there is no value in adding classes and ids but that's this is the wrong place to do so 
     183Jan 13 11:26:13 <Seldaek>       boutell: I'd consider myself well versed in css .. 
     184Jan 13 11:26:14 <boutell>       Seldaek: CSS cannot target a checkbox by itself 
     185Jan 13 11:26:20 <lsmith>        we have done some changes to our form's .. adding some classes etc 
     186Jan 13 11:26:28 <Seldaek>       boutell: input[type="checkbox"] ? 
     187Jan 13 11:26:35 <lsmith>        all via the theming 
     188Jan 13 11:26:51 <boutell>       Seldaek: pardon, if you're concerned about IE6 bc you can't 
     189Jan 13 11:27:04 <Seldaek>       yeah well, I'm not, not for the styles of a checkbox 
     190Jan 13 11:27:12 <lsmith>        for example 
     191Jan 13 11:27:29 *       rande ( has joined #symfony-dev 
     192Jan 13 11:27:33 <Seldaek>       boutell: but then you can just use a ie6_forms.twig 
     193Jan 13 11:27:43 <Seldaek>       seriously IE6 is not a major concern anymore for many people 
     194Jan 13 11:27:48 <pgodel_work>   how do other frameworks deal with this, if any ? 
     195Jan 13 11:27:52 <boutell>       fabpot: how does one theme forms in such a way that your theme applies to all forms that aren't being explicitly themed to the contrary? For instance if there's a form being "just rendered" in some bundle in your project, will it respect your theme? 
     196Jan 13 11:27:57 <Seldaek>       I recognize it's not off the grid entirely, but we shouldn't build with it in mind in the framework 
     197Jan 13 11:27:59 <mvrhov>        well he can just wrap form in a div and give that div a class then he can style.. 
     198Jan 13 11:28:10 <lsmith>        boutell: you can set a theme inside your form class 
     199Jan 13 11:28:22 <fabpot>        boutell: this is configurable, yes. I think it's described in the documentation as well. 
     200Jan 13 11:28:33 <lsmith>        and you can also set a global theme 
     201Jan 13 11:28:41 <boutell>       lsmith: I am asking whether, for a particular project, I can get the same effect I would get if I could convince fabpot to accept my changes to the defaults. It sounds like a global theme does that. 
     202Jan 13 11:28:44 <Seldaek>       boutell: you can override the form templates on a project basis, so it's no problem if the bundle comes with a form.. 
     203Jan 13 11:29:03 <Seldaek>       since the form itself doesn't define its rendering 
     204Jan 13 11:29:07 <boutell>       how do I go about overriding the markup of DateField globally? 
     205Jan 13 11:29:10 <lsmith>        boutell: yes, a global lets you selectively replace the standard form.twig 
     206Jan 13 11:29:20 <Seldaek>       boutell: you override the date_field block in the form.twig 
     207Jan 13 11:29:24 <lsmith>        the link i just pasted just overrides a few blocks .. 
     208Jan 13 11:29:29 <lsmith>        but you can of course override all of them .. 
     209Jan 13 11:29:41 <lsmith>        and you can of course also leave out the extends 
     210Jan 13 11:30:22 <mvrhov>        as other framewroks go.. comming from the Zend one.. it assigns a class to the form element 
     211Jan 13 11:30:24 <fabpot>        boutell: yes, all these things are possible 
     212Jan 13 11:30:27 <lsmith> 
     213Jan 13 11:30:44 <lsmith>        each of these blocks can be overridden individually 
     214Jan 13 11:30:47 <boutell>       lsmith: so how do I configure the project to use this override of form.twig? 
     215Jan 13 11:31:08 <pgodel_work>   mvrhov: I was thinking more in terms of frameworks that are more considerate with UI. ZF is not much of it 
     216Jan 13 11:31:13 <lsmith>        twig.config: 
     217Jan 13 11:31:13 <lsmith>            form: 
     218Jan 13 11:31:13 <lsmith>                resources: ['FooBundle::form.twig'] 
     219Jan 13 11:31:27 <Seldaek>       boutell: can we agree you'll look it up later and skip to the next issue? :) 
     220Jan 13 11:31:30 <boutell>       lsmith: huh. I don't have to say what I'm replacing with it? 
     221Jan 13 11:31:34 <boutell>       Seldaek: yes. 
     222Jan 13 11:31:49 <boutell>       fair enough. I'm new to this channel but I get that it's not the howto channel, if it can be done that's all I should be asking here 
     223Jan 13 11:31:53 <avalanche123>  boutell 
     224Jan 13 11:31:59 <Stof>  boutell: the TwigBundle one will stau here as a fallback 
     225Jan 13 11:32:11 <Stof>  but if you define all the blocks it will never be used 
     226Jan 13 11:32:13 <lsmith>        boutell: its a how to channel .. not necessarily during the meeting :) 
     227Jan 13 11:32:17 <Seldaek>       boutell: I don't mind helping you later, just don't want to "waste" the 1h time slot on support :) 
     228Jan 13 11:32:20 <lsmith>        ok next topic 
     229Jan 13 11:32:22 <lsmith>        RFC for DIC template syntax: 
     230Jan 13 11:32:23 <boutell>       lsmith: OK. I got hauled in kind of randomly (: 
     231Jan 13 11:32:53 <lsmith>        so the point of this RFC is to make it possible to reuse and override templates within an XML/YAML config 
     232Jan 13 11:33:20 <lsmith>        johanness put it best 
     233Jan 13 11:33:27 <lsmith>        I think what you are looking for is the equivalent of 
     234Jan 13 11:33:27 <lsmith>        $definition = clone $container->getDefinition(); 
     235Jan 13 11:33:27 <lsmith>        $arguments = $definition->getArguments(); 
     236Jan 13 11:33:27 <lsmith>        $arguments[3] = $sth; 
     237Jan 13 11:33:27 <lsmith>        $definition->setArguments($arguments); 
     238Jan 13 11:33:27 <lsmith>        $container->setDefinition('', $definition); 
     239Jan 13 11:33:28 <lsmith>        for XML, and YML 
     240Jan 13 11:33:37 <lsmith>        however there is one more bit .. 
     241Jan 13 11:33:51 <lsmith>        i want the name of the service to be derived from the things changed in the definition 
     242Jan 13 11:34:09 <lsmith>        so that if i override a template in different bundles with the same argument changes 
     243Jan 13 11:34:15 <lsmith>        i only end up with one service in the DIC 
     244Jan 13 11:34:20 <johanness>     does that make sense? how would you use this service then? 
     245Jan 13 11:34:26 <johanness>     if you don't know its id 
     246Jan 13 11:34:41 <lsmith>        johanness: look at the example i gave 
     247Jan 13 11:34:57 <lsmith>            MyDefault: 
     248Jan 13 11:34:57 <lsmith>                class: Application\MyBundle\Controller\DefaultController 
     249Jan 13 11:34:57 <lsmith>                arguments: 
     250Jan 13 11:34:57 <lsmith>                    view: @MyService [ fourth: 'this is just a test' ] 
     251Jan 13 11:34:57 <lsmith>                shared: true 
     252Jan 13 11:35:15 <lsmith>        this would take the @MyService template 
     253Jan 13 11:35:27 <johanness>     ah ok you define it inline 
     254Jan 13 11:35:29 <lsmith>        and override the argument 'fourth' with 'this is just a test' 
     255Jan 13 11:35:32 <lsmith>        yes 
     256Jan 13 11:35:44 <lsmith>        and i dont need to know if the same thing is done else where 
     257Jan 13 11:35:46 <lsmith>        or not 
     258Jan 13 11:36:03 <lsmith>        it just does an md5() of the of the arguments 
     259Jan 13 11:36:18 <lsmith>        this is useful when one has to define multiple very similar services 
     260Jan 13 11:36:34 <johanness>     we could set it inline, don't need an id at all in this case 
     261Jan 13 11:36:40 <lsmith>        johanness: ok 
     262Jan 13 11:36:53 <lsmith>        yeah my proposal predates your work on inlining 
     263Jan 13 11:37:05 <lsmith>        so the question is just .. do people think this would be useful? 
     264Jan 13 11:37:26 <lsmith>        one use case is for people that do constructor injection 
     265Jan 13 11:37:44 <lsmith>        and that always have to inject the same services for templating, emailing etc 
     266Jan 13 11:37:56 <lsmith>        and then now and then a different repository depending on the controller 
     267Jan 13 11:38:11 <fabpot>        lsmith: why not use interface injection? 
     268Jan 13 11:38:14 <lsmith>        so they could define a controller template with defaults 
     269Jan 13 11:38:25 <lsmith>        fabpot: interface injection has a serious flaw 
     270Jan 13 11:38:37 <fabpot>        lsmith: ok, why not fix the flaw then 
     271Jan 13 11:38:45 <fabpot>        what is the flaw? 
     272Jan 13 11:38:50 <lsmith>        it means you bind your controller implementation to a specific service name 
     273Jan 13 11:38:57 <lsmith>        fabpot: that flaw is by design 
     274Jan 13 11:39:14 <lsmith>        aka if i implement interface X which injects the service id foobar 
     275Jan 13 11:39:29 <lsmith>        then if i want to change the class for service id foobar .. then i will change it for all my controllers 
     276Jan 13 11:39:37 <jmikola|w>     lsmith: it expects that foobar is the service providing that interface for your entire application 
     277Jan 13 11:39:39 <lsmith>        so i loose a lot of flexibility .. 
     278Jan 13 11:39:58 *       AlHornair has quit (Quit: Ex-Chat) 
     279Jan 13 11:40:10 <lsmith>        this is the reason why i have always been advocating against injecting the container 
     280Jan 13 11:41:13 <lsmith>        i can try to work on this .. but only if we have universal agreement on the principle 
     281Jan 13 11:41:23 <jmikola|w>     regarding the previous code example, i can see why the "fourth: arg" thing could be convenient, but i'm comfortable with how the DIC factories for from Security component 
     282Jan 13 11:41:25 <lsmith>        to me it would be very useful 
     283Jan 13 11:42:24 <lsmith>        jmikola|w: what do you mean with "how the DIC factories for from Security component" ? 
     284Jan 13 11:42:39 <lsmith>        btw .. there is at most 5 mins left in this timebox 
     285Jan 13 11:42:47 <jmikola|w>     Security component has its own service templates, which the factories clone definitions of 
     286Jan 13 11:43:43 <lsmith>        so how would this principle be applied to those using constructor injection to inject a common set of services? 
     287Jan 13 11:43:52 <lsmith>        they would implement a factory? 
     288Jan 13 11:44:01 <lsmith>        which gets a list of service names? 
     289Jan 13 11:44:19 <lsmith>        and parameters .. 
     290Jan 13 11:45:10 <fabpot>        lsmith: as I said before, if we implement something like this (and I'm not convinced yet), you should have a look at Spring templates 
     291Jan 13 11:46:21 *       iAsterisk has quit (Quit: Computer has gone to sleep.) 
     292Jan 13 11:46:37 <lsmith>        fabpot: yeah i tried to google the topic once .. but didnt really find a good source .. then again i am not a spring expert .. so i probably didnt look in the right place 
     293Jan 13 11:46:43 <lsmith>        but anyway .. enough of this topic 
     294Jan 13 11:46:46 <lsmith>        moving on 
     295Jan 13 11:46:48 <lsmith>        Design questions about the Symfony 2 routing and security model: 
     296Jan 13 11:46:54 <lsmith>        another boutell topic 
     297Jan 13 11:47:05 <lsmith>        boutell: want to give us a short summary? or shall I 
     298Jan 13 11:47:37 <lsmith>        ok then i will 
     299Jan 13 11:47:51 <lsmith>        the gist of the issue is that since the firewall is totally separate from the Bundles 
     300Jan 13 11:48:06 <lsmith>        and the routing is separate from the Controllers 
     301Jan 13 11:48:30 <lsmith>        and the firewall working on uri's and not routes 
     302Jan 13 11:48:41 <lsmith>        it means that changing the routes can have tricky effects 
     303Jan 13 11:48:50 *       raulfraile has quit (Quit: Ex-Chat) 
     304Jan 13 11:48:53 <lsmith>        it can lead to things being no longer secured that were before 
     305Jan 13 11:49:16 <lsmith>        or when changing a route to use a uri pattern instead of get/post that the controller needs to be changed 
     306Jan 13 11:49:37 <lsmith>        for the later one approach could be injecting the uri pattern variables also into the request .. 
     307Jan 13 11:49:51 <lsmith>        so that controllers arent forced to pick these parameters up as method parameters 
     308Jan 13 11:50:18 <lsmith>        for the firewall issue .. in sf1 the security settings were set on the actions in the module config 
     309Jan 13 11:50:24 <lsmith>        so much for the summary 
     310Jan 13 11:50:31 <lsmith>        anyone have opinions on this? 
     311Jan 13 11:50:49 <fabpot>        lsmith: security and URLs aren't necesseraly tied together 
     312Jan 13 11:50:57 <fabpot>        I like the way it is right now 
     313Jan 13 11:51:07 <fabpot>        Routing is only a way to convert the path info to parameters, nothing more 
     314Jan 13 11:51:28 <lsmith>        fabpot: so if an action requires being able to get a user object from the security context 
     315Jan 13 11:51:35 <avalanche123>  git stat 
     316Jan 13 11:51:37 <lsmith>        should that action check if the user is logged in? 
     317Jan 13 11:51:38 <avalanche123>  err 
     318Jan 13 11:51:39 <avalanche123>  sorry 
     319Jan 13 11:51:48 <lsmith>        or should i just rely on the firewall being configured properly? 
     320Jan 13 11:52:07 <fabpot>        you should rely on the firewall being configured properly 
     321Jan 13 11:52:13 <lsmith>        k 
     322Jan 13 11:52:22 <Herzult>       The firewall map is not mandatory configured to match url pattern 
     323Jan 13 11:52:34 <lsmith>        and what if i redesign my routes .. to use more uri pattern variables .. is it acceptable that this requires changes in the controller? 
     324Jan 13 11:52:43 <Herzult>       it can match controllers in exemple 
     325Jan 13 11:53:08 <lsmith>        Herzult: ah it can? i guess that would reduce the issue quite a bi 
     326Jan 13 11:53:09 <lsmith>        bit 
     327Jan 13 11:53:32 <Herzult> 
     328Jan 13 11:54:03 *       ornicar ( has joined #symfony-dev 
     329Jan 13 11:54:29 <lsmith>        ok .. so what about uri pattern variables 
     330Jan 13 11:54:51 <lsmith>        should they also be passed as GET parameters to the request object? 
     331Jan 13 11:55:08 <lsmith>        that way developers could forgoe using method parameters for them 
     332Jan 13 11:55:16 <Seldaek>       lsmith: I'd say like you told me about using URLs in functional tests, changing URLs should be a big event ;) 
     333Jan 13 11:55:18 <lsmith>        in order to make it easier to redesign the urls 
     334Jan 13 11:55:44 <lsmith>        Seldaek: yeah .. here however its also a thing in regards to 3rd party controllers 
     335Jan 13 11:56:02 <lsmith>        i guess we could say a best practice for 3rd party controllers is not to use uri pattern variables 
     336Jan 13 11:56:09 <Seldaek>       yup and also security is at stake 
     337Jan 13 11:56:58 <lsmith>        ok .. 3 more minutes 
     338Jan 13 11:57:09 <lsmith>        anyone else habe comments on this topic? 
     339Jan 13 11:57:19 <lsmith>        .. 
     340Jan 13 11:57:28 <lsmith>        otherwise .. thx for your attention .. 
     341Jan 13 11:57:42 <avalanche123>  thank you