IRCLogs20110120 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110120

lsmith (IP:
01/21/11 14:31:42 (7 years ago)



  • IRCLogs20110120

    v0 v1  
     1= Summary = 
     5= IRC logs = 
     7Jan 20 10:59:38 <henrikbjorn>   lsmith? 
     8Jan 20 11:01:05 <Seldaek>       he's sitting beside me 
     9Jan 20 11:01:16 <Seldaek>       let me ping 
     10Jan 20 11:01:57 <lsmith>        ah 
     11Jan 20 11:02:02 <lsmith>        well lets go and stuff 
     12Jan 20 11:02:04 <pgodel_work>   did he fall asleep ? :) 
     13Jan 20 11:02:13 <Seldaek>       nah he was lost in code 
     14Jan 20 11:02:16 <lsmith>        some people have to do real work ... like refactoring unit tests 
     15Jan 20 11:02:23 <pgodel_work>   :) 
     16Jan 20 11:02:27 <lsmith>        so Template names: 
     17Jan 20 11:02:31 <lsmith>        fight! 
     18Jan 20 11:02:49 <Seldaek>       ok, soo.. anyone doesn't have a clear vision of the problem? 
     19Jan 20 11:03:05 <Seldaek>       basically I think having the format at the end is awful for IDEs/syntax highlighting 
     20Jan 20 11:03:21 <Seldaek>       and it'll bite us in the ass in the long term with all the people that'll be confused 
     21Jan 20 11:03:27 <fabpot>        the format and the renderer are the same as far as the IDE is concernted 
     22Jan 20 11:03:35 <naderman>      I think it's good for IDEs/syntax highlighting, because editors that don't know twig won't highlight it at all otherwise 
     23Jan 20 11:03:45 <henrikbjorn>   I agree and fileextensions should identify what type of file it is 
     24Jan 20 11:03:45 <fabpot>        so, a template is about two things: Twig and HTML, or JS and PHP, ... 
     25Jan 20 11:03:54 <Seldaek>       fabpot: the ide just sees a file extension 
     26Jan 20 11:03:55 <jmikola|w>     I think Seldaek posted the example of .twig.html conflicting with .html rules 
     27Jan 20 11:03:56 <fabpot>        so, we need to base our decision based on IDEs behaviors 
     28Jan 20 11:04:10 <pgodel_work>   I like Fabien short summary: "For me, an HTML template is about 
     29Jan 20 11:04:10 <pgodel_work>   a lot of HTML a a few Twig tags. So, the "main" format is definitely HTML. " 
     30Jan 20 11:04:32 <jmikola|w>     also, i know the smarter editors like eclipse will run through .twig.php or .twig.html files and actually consider the files invalid because of intermixed twig syntax 
     31Jan 20 11:04:43 <henrikbjorn>   Fabpot but the files are not html/js they are twig files 
     32Jan 20 11:04:46 <jmikola|w>     not a problem for things like TextMate that just do syntax highlighting, of course 
     33Jan 20 11:04:46 <Seldaek>       fabpot: IDEs can mostly be configured to handle .twig file as .php file, or .html, or .tpl (so they have smarty like highlighting), but you can't tell most IDEs to use .twig.* as a match I think 
     34Jan 20 11:05:04 <henrikbjorn>   No matter in what degree they contain twig tags 
     35Jan 20 11:05:13 <jmikola|w>     Seldaek: I think folks would even want to use .html.twig as html rules, and .php.twig as php rules 
     36Jan 20 11:05:21 *       mpiecko ( has joined #symfony-dev 
     37Jan 20 11:05:26 <fabpot>        Seldaek: the question is: for dumb IDEs that can hightlight both Twig and HTML, which one is better: HTML or Twig? 
     38Jan 20 11:05:26 <jmikola|w>     which should be very simple, since there likely won't be a generic .twig rule to conflict with 
     39Jan 20 11:05:29 <Seldaek>       jmikola|w: well, that's a nice to have sure 
     40Jan 20 11:05:33 <henrikbjorn>   You dont open a jpg file and expect php code 
     41Jan 20 11:05:37 <Seldaek>       fabpot: imo twig 
     42Jan 20 11:05:40 <avalanche123>  what was the default smarty naming convention? .html.tpl or .tpl.html? 
     43Jan 20 11:05:40 <cranberyxl>    henrikbjorn: +1 
     44Jan 20 11:05:56 <jmikola|w>     i believe smarty ends with .tpl, but it's been a while :) 
     45Jan 20 11:06:01 <Seldaek>       fabpot: because html is html, they might support php in it, but if they support twig highlighting they'll support .twig 
     46Jan 20 11:06:03 <henrikbjorn>   Smarty is tpl at the end 
     47Jan 20 11:06:10 <pgodel_work>   you really care about smarty ? ;) 
     48Jan 20 11:06:15 <avalanche123>  doesn't matter how long its been, I think its expected 
     49Jan 20 11:06:22 <pgodel_work>   yeah, tpl 
     50Jan 20 11:06:32 <Seldaek>       avalanche123: it's JUST .tpl, there is no freaking .html in there 
     51Jan 20 11:06:32 <jmikola|w>     avalanche123: i meant it's been a while since i worked with it :) 
     52Jan 20 11:06:45 <fabpot>        so, my personal opinion is that I don't really care. We just need to take a decision and be done with it 
     53Jan 20 11:06:49 <avalanche123>  Seldaek, gotcha 
     54Jan 20 11:06:53 <avalanche123>  fabpot +1 
     55Jan 20 11:07:01 <naderman>      agreed 
     56Jan 20 11:07:02 <lsmith>        i dont care either 
     57Jan 20 11:07:08 <henrikbjorn>   I care :) 
     58Jan 20 11:07:13 <fabpot>        so, the ones who care, speak up! 
     59Jan 20 11:07:19 <avalanche123>  so let's vote then. who's for .html? 
     60Jan 20 11:07:26 <Seldaek>       imo it's simple, file extension defines the content, which in this case the main content is the renderer stuff 
     61Jan 20 11:07:40 <Seldaek>       the rest is added symfony specific meaning 
     62Jan 20 11:07:44 <pgodel_work>   Seldaek: +1 
     63Jan 20 11:07:44 <jmikola|w>     i'm for .twig, even though i really don't want to rename all of our templates again 
     64Jan 20 11:07:46 <Seldaek>       if IDEs decide to support it down the line, great 
     65Jan 20 11:07:49 <Seldaek>       but most won't 
     66Jan 20 11:07:56 <henrikbjorn>   Seldaek exactly 
     67Jan 20 11:07:56 <Stof>  Seldaek: +1 
     68Jan 20 11:08:00 <cranberyxl>    .twig 
     69Jan 20 11:08:02 <everzet>       .twig 
     70Jan 20 11:08:07 <beberlei>      at least IDEs that dont detect a file extension support to add a renderer for it 
     71Jan 20 11:08:13 <henrikbjorn>   Ill gladly do the back porting 
     72Jan 20 11:08:14 <Stof>  .twig 
     73Jan 20 11:08:14 <beberlei>      so you can say in netbeans render .twig as html 
     74Jan 20 11:08:16 <tecbot>        .twig 
     75Jan 20 11:08:20 <mvrhov>        hm I just tired in eclipse *.twihg.html is nogo 
     76Jan 20 11:08:28 <mvrhov>        *.twig.html 
     77Jan 20 11:08:35 <Seldaek>       so.. rename? 
     78Jan 20 11:08:37 <beberlei>      but .twig means .html.twig yah? 
     79Jan 20 11:08:40 <Seldaek>       yes 
     80Jan 20 11:08:42 <everzet>       yep 
     81Jan 20 11:08:42 <Stof>  yes 
     82Jan 20 11:08:43 <henrikbjorn>   Yes 
     83Jan 20 11:08:45 <avalanche123>  beberlei yeah 
     84Jan 20 11:08:49 <Seldaek>       lsmith: next:) 
     85Jan 20 11:09:01 <fabpot>        beberlei: but Twig can be used for HTML, or JS, or anything really. So, to have a good hightlighting, you need an IDE that can do that for Twig AND something else 
     86Jan 20 11:09:06 <lsmith>        Package / Dependency Management for Bundles: 
     87Jan 20 11:09:06 <henrikbjorn>   Ill do it then and finish the pull request 
     88Jan 20 11:09:16 <lsmith>        sorry .. i am a bit busy today .. 
     89Jan 20 11:09:28 <Seldaek>       fabpot: most will default to html+twig, if they support twig at all, then some might get smarter for symfony specific users I guess 
     90Jan 20 11:09:43 <Seldaek>       fabpot: but that's the main use case so I think it's ok 
     91Jan 20 11:09:49 <beberlei>      well having .xml.twig and .html.twig, wwhat do you highlight? 
     92Jan 20 11:09:51 <Seldaek>       and definitely better than no highlighting at all 
     93Jan 20 11:10:00 <bobthecow>     for what it's worth, Coda and SubEthaEdit highlight .twig files. 
     94Jan 20 11:10:05 <jmikola|w>     regarding the dep management, fabpot is there any progress from talking to Brett about Pyrus? 
     95Jan 20 11:10:05 <henrikbjorn>   Beberlei twig 
     96Jan 20 11:10:15 <bobthecow>     .xml.twig is a superset of .xml 
     97Jan 20 11:10:18 <Seldaek>       beberlei: twig tags.. but *.twig files will be seen as html+twig tags 
     98Jan 20 11:10:21 <bobthecow>     .html.twig is a superset of html 
     99Jan 20 11:10:22 <fabpot>        jmikola|w: I was not the one who talked with Pyrus guys 
     100Jan 20 11:10:25 <bobthecow>     should highlight both. 
     101Jan 20 11:10:43 <fabpot>        to sum up my point of view on this topic 
     102Jan 20 11:10:45 <beberlei>      basically both nadermann and me found that pyrus is a piece of garbage 
     103Jan 20 11:11:09 <fabpot>        beberlei: hehe, I would not say that... I mean not in public ;) 
     104Jan 20 11:11:11 <beberlei>      we have to write our pirum for the client side that uses a package.xml  which is extended using a new xml namespace 
     105Jan 20 11:11:29 <lsmith>        i guess now with getParent(), we have linear "dependencies" 
     106Jan 20 11:11:30 <fabpot>        there is really 2 things to cover 
     107Jan 20 11:11:45 <naderman>      well pyrus is not meant to be extensible, and it's written in that way, there are quite a few things that would be nice for Symfony that will be very hard to get into there 
     108Jan 20 11:11:54 <fabpot>        lsmith: yes, but dependencies is also about other libraries like Doctrine, or even jQuery 
     109Jan 20 11:12:14 <lsmith>        fabpot: yeah .. not saying its solved by any means 
     110Jan 20 11:12:18 <beberlei>      fabpot: i will state so publically because i feel i have reviewed the code enough and other people might support me in this 
     111Jan 20 11:12:21 <henrikbjorn>   I think we should focus on backend dependencies 
     112Jan 20 11:12:26 <everzet>       naderman: multiversioning for example ;-) 
     113Jan 20 11:12:26 <naderman>      for other libraries it would be nice to have an installer that can speak regular pear package.xml and maybe even more formats 
     114Jan 20 11:12:36 <Stof>  and you can need FOSUB without overwriting it 
     115Jan 20 11:12:37 <Seldaek>       lsmith: getParent() is NOT defining dependencies at all 
     116Jan 20 11:12:46 <fabpot>        ok, I think it won"t be easy to talk about that here 
     117Jan 20 11:12:48 <Seldaek>       it defines what a bundle overrides 
     118Jan 20 11:13:01 *       bschussek (~yaaic@ has joined #symfony-dev 
     119Jan 20 11:13:14 <fabpot>        As naderman seems really interested by the topic, I propose that we talk together and report on the dev mailing-list for further discussions 
     120Jan 20 11:13:25 <beberlei>      yes that would be great 
     121Jan 20 11:13:27 <Seldaek>       fine by me 
     122Jan 20 11:13:29 <beberlei>      we need a start somewhere 
     123Jan 20 11:13:30 *       lapistano has quit (Excess Flood) 
     124Jan 20 11:13:36 <avalanche123>  +1 
     125Jan 20 11:13:40 <everzet>       +1 
     126Jan 20 11:13:42 <naderman>      fine by me, missed your message this morning btw, sorry 
     127Jan 20 11:13:44 <henrikbjorn>   +1 
     128Jan 20 11:13:50 *       lapistano ( has joined #symfony-dev 
     129Jan 20 11:13:52 <Stof>  +1 
     130Jan 20 11:14:00 <avalanche123>  next:) 
     131Jan 20 11:14:02 <Herzult>       ok, we'll wait for it 
     132Jan 20 11:14:17 *       wSuFF has quit (Disconnected by services) 
     133Jan 20 11:14:26 <Seldaek>       damn it lsmith :p 
     134Jan 20 11:14:36 <lsmith>        refactored bundle management: 
     135Jan 20 11:14:49 <everzet>       love it 
     136Jan 20 11:14:50 <pgodel_work>   github down 
     137Jan 20 11:14:57 <lsmith>        sweet 
     138Jan 20 11:15:02 <lsmith>        so lets get back to that one later 
     139Jan 20 11:15:03 <avalanche123>  I opened it up 
     140Jan 20 11:15:05 <naderman>      so topic is unicorns 
     141Jan 20 11:15:06 <Seldaek>       well, I think we know what it is? 
     142Jan 20 11:15:06 <everzet>       angry unicorn is great 
     143Jan 20 11:15:06 <pgodel_work>   refresh worked 
     144Jan 20 11:15:12 <lsmith>        ah ok 
     145Jan 20 11:15:14 *       devilp ( has joined #symfony-dev 
     146Jan 20 11:15:16 <avalanche123>  refresh... 
     147Jan 20 11:15:17 <cranberyxl>    unicorns fart rainbows 
     148Jan 20 11:15:18 <lsmith>        so lets keep going .. fabpot .. 
     149Jan 20 11:15:21 <henrikbjorn>   We need to define best practices and reflect them in init:bundle 
     150Jan 20 11:15:42 <beberlei>      i guess we agree that the bundle refactoring is great, i just feel that around the best practices there is much discussion, like Bundle in class name and such 
     151Jan 20 11:16:01 <jmikola|w>     beberlei: yes, there was some mailing list discussion about this within the last day i think 
     152Jan 20 11:16:03 <fabpot>        yeah, I think that we are now free to dicuss the naming conventions again 
     153Jan 20 11:16:03 *       rande ( has left #symfony-dev 
     154Jan 20 11:16:14 <fabpot>        I can send a new topic about that now 
     155Jan 20 11:16:22 <Seldaek>       two things I wonder fabpot about that: what does the resolving rules look like when you fetch an asset now, and why Vendor\Bundle\Foo*Bundle*\FooBundle 
     156Jan 20 11:16:41 <fabpot>        for assets, it's exactly as before 
     157Jan 20 11:16:43 <beberlei>      but since with the refactoring you actually could serve several bundles from one directory i say having "VendorCategoryNameBundle" as Bundle class is actually a very good decision 
     158Jan 20 11:16:51 <naderman>      fabpot: will you adjust the sandbox autoload.php to have /vendor/ or /src/ as fallbacks? 
     159Jan 20 11:16:54 <Seldaek>       ok, so you refer to bundles by their getName() value 
     160Jan 20 11:17:15 <jmikola|w>     if Vendor is part of the bundle name, and end user bundles sit alongside vendor bundles, it wasn't clear to me how we can override another bundle 
     161Jan 20 11:17:23 <fabpot>        naderman: quite possible, yes 
     162Jan 20 11:17:32 <fabpot>        Seldaek: the getName() method is gone 
     163Jan 20 11:17:34 <beberlei>      jmikola|w: fabien committed a "getParent()" approach for that just now 
     164Jan 20 11:17:41 <fabpot>        the name is just the short class name 
     165Jan 20 11:17:43 <naderman>      I think it's still unclear if people are going to put their 3rd party bundles in /vendor/ but I guess that's down to package management to a degree 
     166Jan 20 11:17:52 <Seldaek>       jmikola|w: yeah that's my question too, I think to override you gotta use the shortname of your class that returns a getParent() from the bundle you wanna override 
     167Jan 20 11:17:59 <fabpot>        naderman: yes, and Symfony2 does not really care 
     168Jan 20 11:18:07 <jmikola|w>     beberlei: but would my App's version of the bundle i override be named FOSUserBundle? (for instance?) 
     169Jan 20 11:18:15 <jmikola|w>     even though it's not in the FOS namespace but my own? 
     170Jan 20 11:18:35 <beberlei>      jmikola|w: no your app is named as you want, "MyAppBundle" and it has a getParent() that says FOSUserBundle 
     171Jan 20 11:18:37 <jmikola|w>     naderman: ah, i didn't catch that third-party bundles go in /vendor 
     172Jan 20 11:19:00 <beberlei>      fabpot: what you cant do with the 1:1 parent->child approach is having one big application bundle that overrites several bundles 
     173Jan 20 11:19:01 <jmikola|w>     i thought /vendor was just for "component" libs... and all bundles (even submodules from third-parties) are in src/ 
     174Jan 20 11:19:03 <Seldaek>       jmikola|w: it's up to you, but it doesn't really matter, they go anywhere now that there is no more bundle dirs 
     175Jan 20 11:19:07 <naderman>      jmikola|w: re: naming your bundle FOSUserBundle, no why would you? you just return 'FOSUserBundle' in getParent() 
     176Jan 20 11:19:16 <jmikola|w>     naderman: got it 
     177Jan 20 11:19:30 <fabpot>        beberlei: support is possible 
     178Jan 20 11:19:31 <naderman>      jmikola|w: it's been in discussion on the mailinglist for a bit recently 
     179Jan 20 11:19:42 <fabpot>        beberlei: getParent() can just return an array of parents 
     180Jan 20 11:19:52 <fabpot>        beberlei: that's easy to implement, but do we want that? 
     181Jan 20 11:20:09 <naderman>      jmikola|w: the question was whether there was a point in keeping 3rd party Bundles somewhere other than libraries 
     182Jan 20 11:20:10 <beberlei>      not sure, but people are going to ask why they cant to do it 
     183Jan 20 11:20:12 <Seldaek>       fabpot: but then, you do @AppBundle/Resources/.., and the code checks if it's in appbundle, and then if not it has to check all the parents? 
     184Jan 20 11:20:19 *       henrikbjorn has quit (Ping timeout: 276 seconds) 
     185Jan 20 11:20:23 <avalanche123>  hmm, I know I might get killed for this, but what if we registered view names in DIC as parameters and refered to them by parameter key, that would me it overridable on parameter level? 
     186Jan 20 11:20:24 <jmikola|w>     beberlei: are you concerned about overhead of creating bundles to override one resource at a time? 
     187Jan 20 11:20:27 <Seldaek>       fabpot: that seems not to be an improvement in performances compared to the bundle dir approach 
     188Jan 20 11:20:29 <beberlei>      Seldaek: inheritanc eonly works the other way around 
     189Jan 20 11:20:37 <fabpot>        Seldaek: performance is better now 
     190Jan 20 11:20:42 <avalanche123>  then I could define App:Controller:view.twig parameter with wome other value 
     191Jan 20 11:20:46 <avalanche123>  *with 
     192Jan 20 11:20:48 *       henrikbjorn ( has joined #symfony-dev 
     193Jan 20 11:20:50 <Seldaek>       fabpot: so if you wanna override a bundle you have to copy ALL assets from it? 
     194Jan 20 11:20:53 *       wSuFF_ (~wsuff@ has joined #symfony-dev 
     195Jan 20 11:20:57 *       jmikola|w kills avalanche123 
     196Jan 20 11:21:01 <fabpot>        Seldaek: no, just the one you want to override 
     197Jan 20 11:21:10 <fabpot>        it's exactly like what we have today 
     198Jan 20 11:21:13 <Seldaek>       fabpot: yeah, otherwise it falls back to the parent path, taht's what I'm saying 
     199Jan 20 11:21:23 <lsmith>        which fyi doesnt work for symlink 
     200Jan 20 11:21:23 <Seldaek>       but if you do multiple inheritance, you'd have to check many parent paths 
     201Jan 20 11:21:27 <naderman>      so if you have multiple paths it's not just "fallback" 
     202Jan 20 11:21:27 <Seldaek>       so it'd become very slow 
     203Jan 20 11:21:40 <naderman>      *multipl eparents 
     204Jan 20 11:21:43 <fabpot>        Seldaek: but most of the time, you just have one parent and one child 
     205Jan 20 11:21:55 <fabpot>        I don't see why you would want several parents 
     206Jan 20 11:22:04 <fabpot>        you get a third-party bundle and you extend it 
     207Jan 20 11:22:06 <Seldaek>       fabpot: well, I don't know "most of the time" based on what? I could see an app bundle wanting to override many bundles it uses 
     208Jan 20 11:22:13 <beberlei>      what is the convention for overriding bundles now btw? if we have 1:1 inheritance would you name it MyFOSUserBundle ? 
     209Jan 20 11:22:27 <beberlei>      AppFOSUserBundle? 
     210Jan 20 11:22:29 <lsmith>        beberlei: it has a different vendor namespace 
     211Jan 20 11:22:33 <fabpot>        beberlei: each bundle must have a different and unique name 
     212Jan 20 11:22:38 <Stof>  what would be the way to get an overrided template ? the child name or the parent name ? 
     213Jan 20 11:22:40 <Seldaek>       beberlei: you name it AppUserBundle and return FOSUserBundle in getParent 
     214Jan 20 11:22:42 <fabpot>        name == short class name 
     215Jan 20 11:22:46 <beberlei>      ah yeah probably 
     216Jan 20 11:22:47 <lsmith>        src/FOS/UserBundle src/MyVendorNS/UserBundle 
     217Jan 20 11:22:57 <jmikola|w>     avalanche123: in all seriousness view names as DIC params would be a good best practice, but i think there still needs to be an overriding mechanism 
     218Jan 20 11:23:24 <avalanche123>  I was just proposing to modify renderer to look them up in DIC first 
     219Jan 20 11:23:32 <avalanche123>  not changing existing rendering 
     220Jan 20 11:23:58 <Stof>  I think calling FOSUserBundle:User:show.html.twig should look for child bundles, not the opposite 
     221Jan 20 11:24:11 <beberlei>      isnt that how it works? 
     222Jan 20 11:24:18 <jmikola|w>     Stof: this seems like an issue of late-static binding :) 
     223Jan 20 11:24:37 <Stof>  it is not what has been suggested just before 
     224Jan 20 11:24:38 <beberlei>      how would a bundle developer know what name the child has? 
     225Jan 20 11:25:02 <jmikola|w>     i think the logic behind a bundle having a parent is that the child can take the place of the parent's name, correct? 
     226Jan 20 11:25:03 <fabpot>        ok, let me explain 
     227Jan 20 11:25:09 <avalanche123>  I mean since the template names are already shortcuts resolved by convention, wouldn't ability to explicitly short-cut comething be helpful? 
     228Jan 20 11:25:10 <fabpot>        You have bundle A 
     229Jan 20 11:25:13 <fabpot>        B extends A 
     230Jan 20 11:25:27 <lsmith>        just FYI .. there is 5 more minutes on this time box 
     231Jan 20 11:25:29 <fabpot>        So, when you use A:foo.html.twig, Symfony2 will look for the template in B, then A 
     232Jan 20 11:25:36 <beberlei>      yah 
     233Jan 20 11:25:40 <Stof>  ok 
     234Jan 20 11:25:41 <jmikola|w>     fabpot: any concern if there was a C that also extended A? 
     235Jan 20 11:25:46 <beberlei>      what if you do B:foo.html.twig? 
     236Jan 20 11:25:47 <jmikola|w>     or is that an unsupported edge case 
     237Jan 20 11:25:52 <naderman>      jmikola|w: that behaviour is undefined 
     238Jan 20 11:25:53 <fabpot>        If C extends A, you will have an exception 
     239Jan 20 11:25:58 <naderman>      Seldaek suggested to throw an exception 
     240Jan 20 11:25:59 <naderman>      ah 
     241Jan 20 11:25:59 <Stof>  jmikola|w: is it unsupported 
     242Jan 20 11:26:00 <beberlei>      jmikola|w: throws exception 
     243Jan 20 11:26:09 <fabpot>        but C can extends B and B extend A 
     244Jan 20 11:26:19 <jmikola|w>     right, that sounds reasonable then 
     245Jan 20 11:26:27 <fabpot>        have a look at the unit tests 
     246Jan 20 11:26:37 <jmikola|w>     beberlei: i'd think B would go directly to the extending bundle 
     247Jan 20 11:26:46 <jmikola|w>     or possibly something that extended IT 
     248Jan 20 11:26:50 <beberlei>      fabpot: is asking for "B:foo.twig.html" cascaded to the parents also? bi-directional inheritance? 
     249Jan 20 11:26:53 *       bschussek (~yaaic@ has left #symfony-dev 
     250Jan 20 11:26:55 <naderman>      and since it can be dynamic you can even build a C which extends B if it exists and A directly otherwise 
     251Jan 20 11:26:56 <fabpot>        tests/Symfony/Tests/Component/HttpKernel/KernelTest.php 
     252Jan 20 11:27:03 <fabpot>        beberlei: nope 
     253Jan 20 11:27:04 <Stof>  beberlei: seems weird 
     254Jan 20 11:27:09 <beberlei>      yes i know 
     255Jan 20 11:27:11 <beberlei>      just asking 
     256Jan 20 11:27:25 <beberlei>      *preparing zeh pop quiz* :) 
     257Jan 20 11:28:00 *       nielsie has quit (Ping timeout: 264 seconds) 
     258Jan 20 11:28:06 <Seldaek>       ok I guess it makes sense.. but I wonder if everyone is a bit confused here how it's gonna fare with end users.. Let's hope decent docs will help everyone. 
     259Jan 20 11:28:26 *       rande ( has joined #symfony-dev 
     260Jan 20 11:28:44 <fabpot>        Seldaek: I think it's pretty simple to explain in the doc, much easier than the current namespace prefixes 
     261Jan 20 11:28:54 <lsmith>        ok .. next topic then .. 
     262Jan 20 11:28:55 <lsmith>        Change option naming convention to camelcase : 
     263Jan 20 11:28:56 <Seldaek>       fabpot: yeah fair enough :) 
     264Jan 20 11:29:30 <jmikola|w>     looks like bernhard dropped out 
     265Jan 20 11:29:33 <Seldaek>       so, changing all options everywhere except in command line stuff to camelCase.. +1/-1 ? 
     266Jan 20 11:29:41 <henrikbjorn>   -1 
     267Jan 20 11:29:48 *       srohweder has quit (Quit: Lost terminal) 
     268Jan 20 11:29:50 <Seldaek>       I already mentionned the problem before with routing params leaking into php vars which were awkward 
     269Jan 20 11:29:55 <avalanche123>  I don't mind as long as its consistent everywhere 
     270Jan 20 11:30:11 <jmikola|w>     are routing params a concern? that's entirely up to the developer afaik 
     271Jan 20 11:30:20 <Seldaek>       and bernhard mentionned that he'd like to have them so you can reuse option names to assign directly values on to an object's properties 
     272Jan 20 11:30:23 <jmikola|w>     unlike core things like constraints or form options 
     273Jan 20 11:30:30 <avalanche123>  well they sould be comel-cased as they are used in PHP too 
     274Jan 20 11:30:34 <Seldaek>       jmikola|w: well, if we change we change it all.. 
     275Jan 20 11:30:35 <avalanche123>  *camel 
     276Jan 20 11:30:37 <fabpot>        I really dislike camelCase, I really like my underscores in YAML and my - in XML, but consistency is probably the best way to go... unfortunately :( 
     277Jan 20 11:30:43 <henrikbjorn>   Also command 
     278Jan 20 11:30:43 <lsmith>        what would this all cover? how do we deal with DIC parameters that get send to services? 
     279Jan 20 11:30:47 <henrikbjorn>   All or nothing 
     280Jan 20 11:30:59 <avalanche123>  henrikbjorn, fabpot +1 
     281Jan 20 11:31:02 <naderman>      camelCase in xml isn't even that uncommon 
     282Jan 20 11:31:03 <lsmith>        are they camelcase in the DIC? which wouldnt fly well in XML 
     283Jan 20 11:31:08 <naderman>      so I think that's alright 
     284Jan 20 11:31:18 <henrikbjorn>   Lsmith they would be funny looking and camelcase sucks for parameters 
     285Jan 20 11:31:40 <lsmith>        i just cant bare any more of this - to _ conversion code in extensions 
     286Jan 20 11:31:43 <avalanche123>  so now instead of doctrine_odm.mongodb: we would have doctrineOdm.mongodb: ? 
     287Jan 20 11:31:46 <lsmith>        it drives me nuts to read it 
     288Jan 20 11:31:49 <Seldaek>       I don't see the problem with camel case personally, but I think we should also think about service names if we rename all parameters 
     289Jan 20 11:31:52 <avalanche123>  in the yaml app config 
     290Jan 20 11:32:08 <lsmith>        and its a source for bugs for different config formats .. 
     291Jan 20 11:32:09 <jmikola|w>     avalanche123: camel case for acronyms gets weird, too... some people capitalize all of it, others just the first letter 
     292Jan 20 11:32:10 <henrikbjorn>   Avalanche123 yeah 
     293Jan 20 11:32:15 <lsmith>        so what ever gets rid of that .. i would be +1000 
     294Jan 20 11:32:16 <henrikbjorn>   Which sucks 
     295Jan 20 11:32:34 <lsmith>        jmikola|w: i think we have been sticking to ucfirst() for acronyms in many places 
     296Jan 20 11:32:36 <Seldaek>       jmikola|w: I think the standard on that is first letter only, but again, we just have to specify it, then we can point people to it 
     297Jan 20 11:32:55 <avalanche123>  jmikola|w, I think it was decided that a standard it not to uppercase all letter of an acronym, only the first one 
     298Jan 20 11:33:05 <Seldaek>       I don't mind how people do it in their project, but in core we can enforce whatever decision we take 
     299Jan 20 11:33:36 <lsmith>        how do we go about changing this? 
     300Jan 20 11:33:42 <lsmith>        one bundle at a time? 
     301Jan 20 11:33:59 <henrikbjorn>   Was i voted for? 
     302Jan 20 11:34:03 <lsmith>        it will break many open pull requests 
     303Jan 20 11:34:05 <henrikbjorn>   It* 
     304Jan 20 11:34:13 *       unknownbliss (~unknownbl@unaffiliated/unknownbliss) has joined #symfony-dev 
     305Jan 20 11:34:14 <naderman>      Seldaek: acronyms with only one uppercase letter is already being used though, no? 
     306Jan 20 11:34:16 <lsmith>        henrikbjorn: nope .. 
     307Jan 20 11:34:20 <fabpot>        lsmith: it will break EVERYTHING 
     308Jan 20 11:34:23 <beberlei>      camel case in xml? ieeeks! 
     309Jan 20 11:34:23 *       webPragmatist (~webby@unaffiliated/webpragmatist) has left #symfony-dev 
     310Jan 20 11:34:24 <henrikbjorn>   It will break all apps 
     311Jan 20 11:34:33 <lsmith>        yeah 
     312Jan 20 11:34:44 <jmikola|w>     forgive me if this was answered, but wasn't bernhard mostly referring to validator/forms? 
     313Jan 20 11:34:45 <avalanche123>  yeah, seems very messy, will look much more like java 
     314Jan 20 11:34:54 <beberlei>      i thought it was about camel case in php 
     315Jan 20 11:34:56 <jmikola|w>     or those configs really comparable to DIC stuff and routing? 
     316Jan 20 11:34:56 *       webPragmatist (~webby@ has joined #symfony-dev 
     317Jan 20 11:34:56 *       webPragmatist has quit (Changing host) 
     318Jan 20 11:34:56 *       webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev 
     319Jan 20 11:34:57 <beberlei>      not in yml and xml 
     320Jan 20 11:35:06 <lsmith>        seeing beberlei's heart attack .. how do we deal with Doctrine? 
     321Jan 20 11:35:13 <naderman>      beberlei: it's about avoiding to have to convert stuff now ;-) 
     322Jan 20 11:35:15 <beberlei>      i dont comply! 
     323Jan 20 11:35:16 <avalanche123>  jmikola|w for consistency, we would change all or nothing I think 
     324Jan 20 11:35:53 <beberlei>      if its about yml and xml config also i say no 
     325Jan 20 11:36:00 <jmikola|w>     even if we avoided camel case, we'd have to settle between _ and -, correct? i think _ is the most portable (for all the formats) 
     326Jan 20 11:36:07 <beberlei>      if people cant think in contexts then its their problem 
     327Jan 20 11:36:08 <henrikbjorn>   Beberlei same its nasty 
     328Jan 20 11:36:09 <pgodel_work>   if camelCase is used for methods, variables but not for parameters, why does it have to be all the way in configuration ? 
     329Jan 20 11:36:14 <fabpot>        ok, based on the feedback here, I think we need to think about this a bit more before changing anything 
     330Jan 20 11:36:16 <Stof>  beberlei: the problem is that some parameters are defined in XML and used in PHP (for routing for example) 
     331Jan 20 11:36:20 <bobthecow>     beberlei: +1 
     332Jan 20 11:36:22 <Stof>  so they are in both worlds 
     333Jan 20 11:36:33 <jmikola|w>     fabpot: +1 
     334Jan 20 11:36:34 <avalanche123>  after thinking about it more, I am against camel case in yml and xmx 
     335Jan 20 11:36:37 <Seldaek>       the problem is that property names are camelcase, so you can't just remove _'s and be done with it, you gotta uppercase what follows 
     336Jan 20 11:36:49 <henrikbjorn>   Jmikola xml and html uses - which yaml can use too 
     337Jan 20 11:36:51 <mvrhov>        so why don't we normailize everything? 
     338Jan 20 11:36:59 <beberlei>      expensive 
     339Jan 20 11:37:01 <mvrhov>        to camelcase before using it 
     340Jan 20 11:37:01 <bobthecow>     zend has a great library for converting between underscored and camelcase. 
     341Jan 20 11:37:03 <beberlei>      and wasted cpu time 
     342Jan 20 11:37:05 <jmikola|w>     i'm leaning against camel case in general though 
     343Jan 20 11:37:36 <fabpot>        bobthecow: lol 
     344Jan 20 11:38:13 <Seldaek>       beberlei: the problem was that bernhard wants to remap options to object properties in the form framework, and you can't have properties with -, and you don't want properties with _ 
     345Jan 20 11:38:13 <naderman>      library o_O 
     346Jan 20 11:38:16 <bobthecow>     could make a camelcase pass to normalize imported configs. 
     347Jan 20 11:38:35 <Seldaek>       converting automatically will lead to countless WTFs 
     348Jan 20 11:38:38 <Seldaek>       let's not go there 
     349Jan 20 11:38:48 <bobthecow>     not if there's a well defined conversion algorithm. 
     350Jan 20 11:38:51 <Seldaek>       even if it's fast I don't care 
     351Jan 20 11:39:02 <Seldaek>       you type a value in your config, you expect the same in your php code 
     352Jan 20 11:39:27 <avalanche123>  bobthecow, in the code you would have to call $container->getParameter('camelCasedName') still 
     353Jan 20 11:39:39 <bobthecow>     ooh. true. 
     354Jan 20 11:39:50 <fabpot>        I think everything has been said 
     355Jan 20 11:40:02 <fabpot>        and it looks like we won't change the current conventions anytime soon 
     356Jan 20 11:40:18 <Seldaek>       yeah, let's see what bernhard thinks after reading the log :) 
     357Jan 20 11:40:23 <avalanche123>  :) 
     358Jan 20 11:40:39 <lsmith>        ok 
     359Jan 20 11:40:41 *       nielsie ( has joined #symfony-dev 
     360Jan 20 11:40:48 <lsmith>        next topic 
     361Jan 20 11:41:05 <lsmith>        this one only has 3 votes .. but thats because i screwed up and a few votes got deleted 
     362Jan 20 11:41:05 <lsmith>        load extension configs once:, 
     363Jan 20 11:41:14 <lsmith>        johanness created a branch 
     364Jan 20 11:41:17 <jmikola|w> 
     365Jan 20 11:41:24 <lsmith>        right 
     366Jan 20 11:41:29 <lsmith>        this is only the first step of course 
     367Jan 20 11:41:29 <jmikola|w>     fabpot: did you get my github response about this? 
     368Jan 20 11:41:38 <lsmith>        we will want to add smarter merging algo's 
     369Jan 20 11:41:40 <fabpot>        jmikola|w: hmmm, not sure 
     370Jan 20 11:41:45 *       iAsteris_ has quit (Quit: Computer has gone to sleep.) 
     371Jan 20 11:41:50 <lsmith>        rather than just replicating the existing approach of calling the load methods for each config 
     372Jan 20 11:41:59 <jmikola|w>     so lsmith alerted me to johannes work after our convo tuesday (when you asked about me doing this) 
     373Jan 20 11:42:00 *       wSuFF_ has quit (Quit: Computer has gone to sleep.) 
     374Jan 20 11:42:17 <fabpot>        lsmith: Don't even think about merging algo. Merging is the responsibility of each extension. 
     375Jan 20 11:42:17 <jmikola|w>     johanness was in support of not having a separate merge method, as not everyone will need it 
     376Jan 20 11:42:27 <lsmith>        fabpot: thats what i mean 
     377Jan 20 11:42:32 <jmikola|w>     so he passes all the configs to the load() method 
     378Jan 20 11:42:44 <lsmith>        the above patch updates all extensions to loop over all configs and call the load method 
     379Jan 20 11:42:53 <lsmith>        which is exactly the behavior we have now 
     380Jan 20 11:43:00 <fabpot>        as johanness  and jmikola|w  is working on the topic, and as it's not finished yet, do we want to re-talk about that now? 
     381Jan 20 11:43:05 <jmikola|w>     his commit isn't thoroughly tested, but it's fairly backwards compatible and we could start transitioning to make the merging as we have time 
     382Jan 20 11:43:06 <lsmith>        and then in step two we update the extensions to do something intelligent 
     383Jan 20 11:43:16 <fabpot>        lsmith: yes, that was not what we decided last time IIRC 
     384Jan 20 11:43:19 <avalanche123>  I agree with fabpot, let's table it for later discussion 
     385Jan 20 11:43:23 <lsmith>        fabpot: the main question is if we agree on the API 
     386Jan 20 11:43:34 <lsmith>        aka the load method gets an array with all the configs 
     387Jan 20 11:43:39 <jmikola|w>     well, if johanness's patch is BC and we can get it into core, people can start working off that to port extensions over 
     388Jan 20 11:44:12 <Stof>  fabpot: lsmith is talking about each core extension, not about creating a generic load method 
     389Jan 20 11:44:12 <jmikola|w>     it would be a bit more difficult coordinating a giant pull request with many hands involved to port all the extensions at once 
     390Jan 20 11:44:13 <lsmith>        basically imho the patch is ready to be pulled 
     391Jan 20 11:44:16 <Seldaek>       lsmith: why not call a merge method with all config arrays, so by default it's implemented as foreach($configs as $config) $this->load($config), and if you like smarter you override 
     392Jan 20 11:44:35 <lsmith>        Seldaek: if at all .. the default merge method would return the last 
     393Jan 20 11:44:38 <lsmith>        but its not possible 
     394Jan 20 11:44:39 <fabpot>        we talked about what to do last time, and we need to stick with it, except if something happened in the meantime 
     395Jan 20 11:44:45 <lsmith>        since you can have multiple load methods 
     396Jan 20 11:44:51 <lsmith>        you need multiple merge methods 
     397Jan 20 11:44:53 <Seldaek>       lsmith: ah right 
     398Jan 20 11:44:57 <Seldaek>       nvm then 
     399Jan 20 11:45:06 <lsmith>        which means a default is impossible without a method exists check 
     400Jan 20 11:45:12 <lsmith>        which is why i think a single load method is the way to go 
     401Jan 20 11:45:15 <lsmith>        no merge method 
     402Jan 20 11:45:28 <naderman>      I'd just like to suggest that there are some convenience methods for merging configurations you can use, so stuff like those remap methods we've seen aren't copy&pasted into all extensions that need them 
     403Jan 20 11:45:30 <Stof>  yeah, johannes patch seems good. 
     404Jan 20 11:45:35 <lsmith>        last time IIRC we wanted a merge method .. 
     405Jan 20 11:45:37 <jmikola|w>     lsmith: i suppose one question on johanness' patch... he has a protected method and one public, which makes unit testing the loading and merging independently not trivial 
     406Jan 20 11:45:49 <Seldaek>       makes sense, and the fact that you get an array of configs is probably better so that every extension developer is aware of the problem that they get multiple configs (and not just one pass) 
     407Jan 20 11:46:05 <lsmith>        jmikola|w: just unit test the protected one via the public one 
     408Jan 20 11:46:09 <lsmith>        or use proxies .. 
     409Jan 20 11:46:21 <lsmith>        or for most cases i dont think the load will do much of anything fancy 
     410Jan 20 11:46:25 <Stof>  then the core extensions will need to be refactored to be sure the merging is the best used 
     411Jan 20 11:46:27 <jmikola|w>     is that what we'll do for core unit tests, though? 
     412Jan 20 11:46:31 <fabpot>        Seldaek: true 
     413Jan 20 11:46:33 <lsmith>        so i wouldnt even bother with unit (maybe functional tests) 
     414Jan 20 11:46:33 *       AlHornair has quit (Quit: Ex-Chat) 
     415Jan 20 11:46:39 <jmikola|w>     lsmith: agreed, the merging logic is essentially, at some point in the config block, you just override keys 
     416Jan 20 11:47:21 <beberlei>      lsmith: i disagree 
     417Jan 20 11:47:21 <lsmith>        ok .. sounds like the branch is good and the next step is updating each extension 
     418Jan 20 11:47:29 <jmikola|w>     so, if johanness' branch can get into core, i will take on porting over FrameworkExtension 
     419Jan 20 11:47:34 <beberlei>      the merging is pretty complicated in case of security or doctrine extension 
     420Jan 20 11:47:39 <beberlei>      i want to test it withought hickups 
     421Jan 20 11:47:39 <jmikola|w>     I assume johanness would do Security - but we can coordinate on the mailing list 
     422Jan 20 11:47:42 <lsmith>        beberlei: unit test junkies need to know how to do proxies 
     423Jan 20 11:47:58 <avalanche123>  beberlei +1 this method should be explicit and public 
     424Jan 20 11:48:09 <beberlei>      has nothing to do with junkie, i want to stuff two arrays in get one array out 
     425Jan 20 11:48:17 <beberlei>      what proxy btw? 
     426Jan 20 11:48:26 <beberlei>      to detect hundrets of calls to the container? 
     427Jan 20 11:48:36 <lsmith>        beberlei: to test protected methods in unit tests you need to create a proxy with adjusted visibility 
     428Jan 20 11:48:42 <lsmith>        anyway .. off topic 
     429Jan 20 11:48:50 <beberlei>      ah that ugly thing :) 
     430Jan 20 11:48:52 <avalanche123>  lsmith if you are testing protected methods, you're doing it wrong:) 
     431Jan 20 11:48:52 <jmikola|w>     beberlei: i think a sane unit test would just pass in a virgin ContainerBuilder and then assert it's state after - no crazy mocking 
     432Jan 20 11:48:55 <Stof>  beberlei: johannes patch does exactly what is actually done in the extension by loading each config separatlty 
     433Jan 20 11:48:56 <naderman>      lsmith: hence the suggestion not to have it protected 
     434Jan 20 11:49:00 *       henrikbjorn has quit (Ping timeout: 264 seconds) 
     435Jan 20 11:49:06 *       daniel123 ( has joined #symfony-dev 
     436Jan 20 11:49:10 <lsmith>        but its not called from the outside 
     437Jan 20 11:49:20 <lsmith>        the load method is .. and then it does whatever it pleases 
     438Jan 20 11:49:26 *       henrikbjorn ( has joined #symfony-dev 
     439Jan 20 11:49:34 <Stof>  and it is not even mandatory if it uses a true merging 
     440Jan 20 11:49:37 <lsmith>        it can just do $config = array_pop($configs) 
     441Jan 20 11:49:42 <lsmith>        and not bother with a separate method at all 
     442Jan 20 11:49:50 <avalanche123>  that I agree with 
     443Jan 20 11:50:00 <lsmith>        so why make two methods public? 
     444Jan 20 11:50:05 <jmikola|w>     lsmith: then perhaps to set a good example for core extensions would be to do the merging in a separate method, even if that's not a required interface? 
     445Jan 20 11:50:05 *       Garfield-fr has quit (Quit:  ⏏) 
     446Jan 20 11:50:08 <lsmith>        there is only a need for one 
     447Jan 20 11:50:09 <beberlei>      jmikola|w ok you are right 
     448Jan 20 11:50:10 <avalanche123>  beberlei, I think if merging gets too complicated, you could extract a Merger... dunno 
     449Jan 20 11:50:19 <beberlei>      virgin container + asserting there is good 
     450Jan 20 11:50:32 <lsmith>        simple extension dont need one, complex one will have one 
     451Jan 20 11:50:33 <lsmith>        yes 
     452Jan 20 11:50:45 <lsmith>        ok .. we only have 10 minutes .. 
     453Jan 20 11:50:51 <lsmith>        lets go to the next topic, ok? 
     454Jan 20 11:50:54 <avalanche123>  sure 
     455Jan 20 11:50:55 <lsmith>        Request changes: 
     456Jan 20 11:51:02 <lsmith>        avalanche123: take it away 
     457Jan 20 11:51:06 <avalanche123>  hi 
     458Jan 20 11:51:13 <avalanche123>  so basically here is my point of view 
     459Jan 20 11:51:23 <avalanche123>  request -> parameters -> controller -> parameters -> view 
     460Jan 20 11:51:31 <avalanche123>  for requests with request body 
     461Jan 20 11:51:45 <avalanche123>  the body needs to be parsed into $request arguments 
     462Jan 20 11:52:08 <avalanche123>  that way you could have the same controller handle json and form requests 
     463Jan 20 11:52:13 <avalanche123>  *ideally* 
     464Jan 20 11:52:33 <avalanche123>  so then we would have request body parsers (whatever you call them) 
     465Jan 20 11:52:39 <henrikbjorn>   I dont get that 
     466Jan 20 11:52:48 <avalanche123>  form post looks like 
     467Jan 20 11:52:49 <henrikbjorn>   Why cant it do that now? 
     468Jan 20 11:52:59 <avalanche123>  key=val&key2=val 
     469Jan 20 11:53:07 <jmikola|w>     henrikbjorn: currently it sets request property based on $_POST 
     470Jan 20 11:53:14 <avalanche123>  henrikbjorn right now request gets whatever is in $_POST 
     471Jan 20 11:53:27 <avalanche123>  but for json and xml requests, that array is empty 
     472Jan 20 11:53:31 <kriswallsmith> how would you read the request body? 
     473Jan 20 11:53:36 <jmikola|w>     so avalanche123 is proposing changing the default request value based on the content-type of the http request 
     474Jan 20 11:53:38 <avalanche123>  as you post a jxon object 
     475Jan 20 11:54:02 *       kertz_ (~kertz@ has joined #symfony-dev 
     476Jan 20 11:54:11 <avalanche123>  form post has content type of application/x-*www-form*-*urlencoded* 
     477Jan 20 11:54:12 <naderman>      kriswallsmith: http_get_request_body() ? 
     478Jan 20 11:54:22 <Seldaek>       btw just so everyone knows (I already told avalanche123), I started working on a Serializer component (that the new fabpot-compliant View would be based on), this could also be used to decode http POST data 
     479Jan 20 11:54:23 <avalanche123>  and json post would be application/json 
     480Jan 20 11:54:44 <avalanche123>  so you could chose how to process request body based on content-type 
     481Jan 20 11:54:44 <igorw> naderman: that's pecl 
     482Jan 20 11:54:48 <naderman>      oh 
     483Jan 20 11:55:06 <avalanche123>  but to do that we would have to change how request is initialized 
     484Jan 20 11:55:08 <Seldaek>       kriswallsmith: you can file_get_contents('php://input') as well to read the body 
     485Jan 20 11:55:12 <henrikbjorn>   Is this in correspondance with the http protocol? 
     486Jan 20 11:55:14 <fabpot>        avalanche123: we already had a pull request for that, and it was rejected as too magic was involved 
     487Jan 20 11:55:21 *       tecbot has quit () 
     488Jan 20 11:55:22 <fabpot>        so it should be done outside of the Request class 
     489Jan 20 11:55:31 <avalanche123>  fabpot, I agree 
     490Jan 20 11:55:40 <avalanche123>  so my point was to make Kernel populate empty request 
     491Jan 20 11:55:47 <fabpot>        but, I'm in favor of having something to deal with that 
     492Jan 20 11:55:50 <avalanche123>  instead of request populating itself 
     493Jan 20 11:56:02 <jmikola|w>     avalanche123: i think request can still default to $_POST though, right? 
     494Jan 20 11:56:05 <avalanche123>  so the request class would be very similar to response class 
     495Jan 20 11:56:16 <jmikola|w>     or would that default value be removed entirely 
     496Jan 20 11:56:28 <naderman>      fabpot: well I think it makes sense for the request class to provide the raw data, and Seldaek's (un)serializer to handle the conversion to objects later 
     497Jan 20 11:56:29 <avalanche123>  it would be registered on application/x-*www-form*-*urlencoded*  request type 
     498Jan 20 11:56:33 *       kertz has quit (Ping timeout: 240 seconds) 
     499Jan 20 11:56:33 *       kertz_ is now known as kertz 
     500Jan 20 11:56:35 <fabpot>        avalanche123: that's a small change and seems reasonnable. You need to check that it does not break anything. 
     501Jan 20 11:56:35 <avalanche123>  and the multipart one 
     502Jan 20 11:56:38 <mvrhov>        Seldaek, weren't there some problems with php://input ? 
     503Jan 20 11:56:46 <fabpot>        naderman: yes 
     504Jan 20 11:56:57 <avalanche123>  fabpot, yeah, I will start on it and ping you with questions if anything 
     505Jan 20 11:57:09 <Seldaek>       mvrhov: it can just be read once, but that's it 
     506Jan 20 11:57:20 <avalanche123>  and we don't need more than once 
     507Jan 20 11:57:23 <lsmith>        ok .. last topic spills over from this one .. Parameter converters: 
     508Jan 20 11:57:23 <Seldaek>       mvrhov: well, only once on SOME SAPIs, but it's available everywhere 
     509Jan 20 11:57:30 <fabpot>        Seldaek: but the request already take care of that 
     510Jan 20 11:57:31 <avalanche123>  me again:) 
     511Jan 20 11:57:42 <avalanche123>  I think it was clear what it was about to everyone on the ml 
     512Jan 20 11:57:43 <Seldaek>       fabpot: yeah sure, I was just answering kriswallsmith's question : 
     513Jan 20 11:58:09 <avalanche123>  basically making explicit registration of parameter converter per parameter would allow for bi-directional conversion 
     514Jan 20 11:58:34 <avalanche123>  fabpot to your point about routing component's responsibility, I think we could just create a custom loader in framework bundle 
     515Jan 20 11:58:42 <avalanche123>  that would take parameters: into account 
     516Jan 20 11:58:44 <beberlei>      is that a necessary use-case? 
     517Jan 20 11:59:00 <avalanche123>  beberlei I dunno, seems useful 
     518Jan 20 11:59:02 <beberlei>      i mean i really know how i convert my object back to an identifier when i am using Router::generate 
     519Jan 20 11:59:07 *       ornicar (~ornicar@ has joined #symfony-dev 
     520Jan 20 11:59:08 <fabpot>        avalanche123: routing does one thing and it won't do anything else. I won't re-create the ObjectRoute nightmare from symfony1 
     521Jan 20 11:59:23 <avalanche123>  I am not familiar with that:) 
     522Jan 20 11:59:26 <fabpot>        beberlei: +1 
     523Jan 20 11:59:32 <fabpot>        avalanche123: trust me 
     524Jan 20 11:59:34 <jmikola|w>     avalanche123: that's what i was talking to you about the other day 
     525Jan 20 11:59:42 <avalanche123>  I get your point:) 
     526Jan 20 11:59:49 <henrikbjorn>   I think maybe we should slim them down and not send the request with the apply method? 
     527Jan 20 12:00:25 <kriswallsmith> i think you can only read from php://input once 
     528Jan 20 12:00:28 <Seldaek>       avalanche123: I think that thing could be built on top of controllers with annotations (at least for the deserializing) 
     529Jan 20 12:00:37 <naderman>      kriswallsmith: yes, see fabpot's answer above 
     530Jan 20 12:00:55 <avalanche123>  Seldaek, yeah, I will have to see about that 
     531Jan 20 12:01:01 <fabpot>        Seldaek: that's what I started in FrameworkExtraBundle 
     532Jan 20 12:01:15 <avalanche123>  fabpot, should we get rid of them period? 
     533Jan 20 12:01:15 <Seldaek>       yup, I think it's not something that needs to be in core 
     534Jan 20 12:01:22 <Seldaek>       and we should forget about it until final is out :) 
     535Jan 20 12:01:33 <fabpot>        Seldaek: hehe, +1 
     536Jan 20 12:01:49 <henrikbjorn>   Maybe we should moe them back out of core? 
     537Jan 20 12:01:52 <fabpot>        avalanche123: I think we need to work on more important features for now 
     538Jan 20 12:01:52 <Seldaek>       there's enough other things to tend to I guess 
     539Jan 20 12:02:06 <avalanche123>  fabpot agreed 
     540Jan 20 12:02:14 <Seldaek>       fabpot: I'll submit that serializer thingy this weekend hopefully.. at least a basic version for review 
     541Jan 20 12:02:16 <fabpot>        henrikbjorn: yeah, that's what I was thinking 
     542Jan 20 12:02:26 <henrikbjorn>   Lets do that 
     543Jan 20 12:02:31 <avalanche123>  henrikbjorn +1 
     544Jan 20 12:02:38 <lsmith>        ok .. 
     545Jan 20 12:02:43 <lsmith>        guess time is up and stuff 
     546Jan 20 12:02:53 <beberlei>      yay to the alc now 
     547Jan 20 12:02:55 <beberlei>      err 
     548Jan 20 12:03:00 <lsmith>        thx for everybody talking so much ... summary will be a ton of work :-/ 
     549Jan 20 12:03:04 <henrikbjorn>   Fabpot should it still rely on annotations in frameworkextra? 
     550Jan 20 12:03:12 <avalanche123>  thanks for great discussion 
     551Jan 20 12:03:13 <beberlei>      lsmith: we know how to make you happy 
     552Jan 20 12:03:31 <fabpot>        henrikbjorn: it already does not rely on annotations, except if you want to pass parameters 
     553Jan 20 12:03:35 <lsmith>        i need a padawan for this stuff 
     554Jan 20 12:03:46 <weaverryan>    lsmith: Thanks for doing the summary though - I missed almost all of this meeting 
     555Jan 20 12:03:48 <beberlei>      i thought that was Seldaek ? :) 
     556Jan 20 12:03:50 <Seldaek>       lsmith: and for extra fun jmikola|w didn't copy the log this time so you gotta do it yourself :P 
     557Jan 20 12:03:59 <jmikola|w>     Seldaek: i'm doing it now :)