The main concern with the approach of renderer.format was that IDE's will not handle this out of the box and many not even via configuration. As a result it was agreed to revert back to format.renderer.
Package / Dependency Management for Bundles
Benjamin reported that he (and Nils) had reviewed Pyrus for our use case an found the code insufficient out of the box and not clean enough for extending. He proposed to write a client companion for Pirum that is based on the package.xml, but adds optional extensions where needed. It was decided to leave this topic in the hands of Nils for now.
refactored bundle management
Now that the bundle handling has been refactored, making things more flexible the best practices need to be reviewed so that they can be baked into init:bundle. However no decisions were made. The behavior of the new getParent() method to allow extending 3rd party bundles was discussed in much detail
Change option naming convention to camelcase
In general there was agreement that the situation of having underscore in YAML, dash in XML and camelcase in PHP to be quite annoying. However as YAML/XML is used to set config options inside PHP code its hard to find a solution. Jeremy also raised the questions how we deal with acronym case to which the unanimous reply was ucfirst(). Considering that changing this will have a huge impact and there wasn't total agreement on one approach the topic was shelved for now.
load extension configs once
It was agreed that Johannes approach is the right starting point. However there was a lot of back and forth if there should be a separate merge method or not and which parts of the API should be public.
Bulat suggested moving the population of Request with the request parameters to the kernel. This would enable easier handling of alternate methods for other methods of passing request parameters. The suggestion was deemed plausible.
Bulat advocated "making explicit registration of parameter converter per parameter would allow for bi-directional conversion". Fabien made it clear he wants the routing rules to remain focused on routing, due to the bad experience with ObjectRoute?'s in sf 1.x. Jordi said he would prefer this be handled inside the Controllers via Annotations, which Fabien mentioned he started in FrameworkExtraBundle?. Henrik suggested that it might be a good idea to move the current parameter converted out of core. Bulat said he will work on the concept some more. Finally Jordi mentioned that he is planning to submit a Serializer component which enables encoding and decoding data structures which should be useful for parameter converters.
Jan 20 10:59:38 <henrikbjorn> lsmith? Jan 20 11:01:05 <Seldaek> he's sitting beside me Jan 20 11:01:16 <Seldaek> let me ping Jan 20 11:01:57 <lsmith> ah Jan 20 11:02:02 <lsmith> well lets go and stuff Jan 20 11:02:04 <pgodel_work> did he fall asleep ? :) Jan 20 11:02:13 <Seldaek> nah he was lost in code Jan 20 11:02:16 <lsmith> some people have to do real work ... like refactoring unit tests Jan 20 11:02:23 <pgodel_work> :) Jan 20 11:02:27 <lsmith> so Template names: http://bit.ly/eYeTyW Jan 20 11:02:31 <lsmith> fight! Jan 20 11:02:49 <Seldaek> ok, soo.. anyone doesn't have a clear vision of the problem? Jan 20 11:03:05 <Seldaek> basically I think having the format at the end is awful for IDEs/syntax highlighting Jan 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 Jan 20 11:03:27 <fabpot> the format and the renderer are the same as far as the IDE is concernted Jan 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 Jan 20 11:03:45 <henrikbjorn> I agree and fileextensions should identify what type of file it is Jan 20 11:03:45 <fabpot> so, a template is about two things: Twig and HTML, or JS and PHP, ... Jan 20 11:03:54 <Seldaek> fabpot: the ide just sees a file extension Jan 20 11:03:55 <jmikola|w> I think Seldaek posted the example of .twig.html conflicting with .html rules Jan 20 11:03:56 <fabpot> so, we need to base our decision based on IDEs behaviors Jan 20 11:04:10 <pgodel_work> I like Fabien short summary: "For me, an HTML template is about Jan 20 11:04:10 <pgodel_work> a lot of HTML a a few Twig tags. So, the "main" format is definitely HTML. " Jan 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 Jan 20 11:04:43 <henrikbjorn> Fabpot but the files are not html/js they are twig files Jan 20 11:04:46 <jmikola|w> not a problem for things like TextMate that just do syntax highlighting, of course Jan 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 Jan 20 11:05:04 <henrikbjorn> No matter in what degree they contain twig tags Jan 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 Jan 20 11:05:21 * mpiecko (mpiecko@HSI-KBW-109-192-054-025.hsi6.kabel-badenwuerttemberg.de) has joined #symfony-dev Jan 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? Jan 20 11:05:26 <jmikola|w> which should be very simple, since there likely won't be a generic .twig rule to conflict with Jan 20 11:05:29 <Seldaek> jmikola|w: well, that's a nice to have sure Jan 20 11:05:33 <henrikbjorn> You dont open a jpg file and expect php code Jan 20 11:05:37 <Seldaek> fabpot: imo twig Jan 20 11:05:40 <avalanche123> what was the default smarty naming convention? .html.tpl or .tpl.html? Jan 20 11:05:40 <cranberyxl> henrikbjorn: +1 Jan 20 11:05:56 <jmikola|w> i believe smarty ends with .tpl, but it's been a while :) Jan 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 Jan 20 11:06:03 <henrikbjorn> Smarty is tpl at the end Jan 20 11:06:10 <pgodel_work> you really care about smarty ? ;) Jan 20 11:06:15 <avalanche123> doesn't matter how long its been, I think its expected Jan 20 11:06:22 <pgodel_work> yeah, tpl Jan 20 11:06:32 <Seldaek> avalanche123: it's JUST .tpl, there is no freaking .html in there Jan 20 11:06:32 <jmikola|w> avalanche123: i meant it's been a while since i worked with it :) Jan 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 Jan 20 11:06:49 <avalanche123> Seldaek, gotcha Jan 20 11:06:53 <avalanche123> fabpot +1 Jan 20 11:07:01 <naderman> agreed Jan 20 11:07:02 <lsmith> i dont care either Jan 20 11:07:08 <henrikbjorn> I care :) Jan 20 11:07:13 <fabpot> so, the ones who care, speak up! Jan 20 11:07:19 <avalanche123> so let's vote then. who's for .html? Jan 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 Jan 20 11:07:40 <Seldaek> the rest is added symfony specific meaning Jan 20 11:07:44 <pgodel_work> Seldaek: +1 Jan 20 11:07:44 <jmikola|w> i'm for .twig, even though i really don't want to rename all of our templates again Jan 20 11:07:46 <Seldaek> if IDEs decide to support it down the line, great Jan 20 11:07:49 <Seldaek> but most won't Jan 20 11:07:56 <henrikbjorn> Seldaek exactly Jan 20 11:07:56 <Stof> Seldaek: +1 Jan 20 11:08:00 <cranberyxl> .twig Jan 20 11:08:02 <everzet> .twig Jan 20 11:08:07 <beberlei> at least IDEs that dont detect a file extension support to add a renderer for it Jan 20 11:08:13 <henrikbjorn> Ill gladly do the back porting Jan 20 11:08:14 <Stof> .twig Jan 20 11:08:14 <beberlei> so you can say in netbeans render .twig as html Jan 20 11:08:16 <tecbot> .twig Jan 20 11:08:20 <mvrhov> hm I just tired in eclipse *.twihg.html is nogo Jan 20 11:08:28 <mvrhov> *.twig.html Jan 20 11:08:35 <Seldaek> so.. rename? Jan 20 11:08:37 <beberlei> but .twig means .html.twig yah? Jan 20 11:08:40 <Seldaek> yes Jan 20 11:08:42 <everzet> yep Jan 20 11:08:42 <Stof> yes Jan 20 11:08:43 <henrikbjorn> Yes Jan 20 11:08:45 <avalanche123> beberlei yeah Jan 20 11:08:49 <Seldaek> lsmith: next:) Jan 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 Jan 20 11:09:06 <lsmith> Package / Dependency Management for Bundles: http://bit.ly/fyCiK6 Jan 20 11:09:06 <henrikbjorn> Ill do it then and finish the pull request Jan 20 11:09:16 <lsmith> sorry .. i am a bit busy today .. Jan 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 Jan 20 11:09:43 <Seldaek> fabpot: but that's the main use case so I think it's ok Jan 20 11:09:49 <beberlei> well having .xml.twig and .html.twig, wwhat do you highlight? Jan 20 11:09:51 <Seldaek> and definitely better than no highlighting at all Jan 20 11:10:00 <bobthecow> for what it's worth, Coda and SubEthaEdit highlight .twig files. Jan 20 11:10:05 <jmikola|w> regarding the dep management, fabpot is there any progress from talking to Brett about Pyrus? Jan 20 11:10:05 <henrikbjorn> Beberlei twig Jan 20 11:10:15 <bobthecow> .xml.twig is a superset of .xml Jan 20 11:10:18 <Seldaek> beberlei: twig tags.. but *.twig files will be seen as html+twig tags Jan 20 11:10:21 <bobthecow> .html.twig is a superset of html Jan 20 11:10:22 <fabpot> jmikola|w: I was not the one who talked with Pyrus guys Jan 20 11:10:25 <bobthecow> should highlight both. Jan 20 11:10:43 <fabpot> to sum up my point of view on this topic Jan 20 11:10:45 <beberlei> basically both nadermann and me found that pyrus is a piece of garbage Jan 20 11:11:09 <fabpot> beberlei: hehe, I would not say that... I mean not in public ;) Jan 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 Jan 20 11:11:29 <lsmith> i guess now with getParent(), we have linear "dependencies" Jan 20 11:11:30 <fabpot> there is really 2 things to cover Jan 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 Jan 20 11:11:54 <fabpot> lsmith: yes, but dependencies is also about other libraries like Doctrine, or even jQuery Jan 20 11:12:14 <lsmith> fabpot: yeah .. not saying its solved by any means Jan 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 Jan 20 11:12:21 <henrikbjorn> I think we should focus on backend dependencies Jan 20 11:12:26 <everzet> naderman: multiversioning for example ;-) Jan 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 Jan 20 11:12:36 <Stof> and you can need FOSUB without overwriting it Jan 20 11:12:37 <Seldaek> lsmith: getParent() is NOT defining dependencies at all Jan 20 11:12:46 <fabpot> ok, I think it won"t be easy to talk about that here Jan 20 11:12:48 <Seldaek> it defines what a bundle overrides Jan 20 11:13:01 * bschussek (~email@example.com) has joined #symfony-dev Jan 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 Jan 20 11:13:25 <beberlei> yes that would be great Jan 20 11:13:27 <Seldaek> fine by me Jan 20 11:13:29 <beberlei> we need a start somewhere Jan 20 11:13:30 * lapistano has quit (Excess Flood) Jan 20 11:13:36 <avalanche123> +1 Jan 20 11:13:40 <everzet> +1 Jan 20 11:13:42 <naderman> fine by me, missed your message this morning btw, sorry Jan 20 11:13:44 <henrikbjorn> +1 Jan 20 11:13:50 * lapistano (~firstname.lastname@example.org) has joined #symfony-dev Jan 20 11:13:52 <Stof> +1 Jan 20 11:14:00 <avalanche123> next:) Jan 20 11:14:02 <Herzult> ok, we'll wait for it Jan 20 11:14:17 * wSuFF has quit (Disconnected by services) Jan 20 11:14:26 <Seldaek> damn it lsmith :p Jan 20 11:14:36 <lsmith> refactored bundle management: http://bit.ly/dVBui4 Jan 20 11:14:49 <everzet> love it Jan 20 11:14:50 <pgodel_work> github down Jan 20 11:14:57 <lsmith> sweet Jan 20 11:15:02 <lsmith> so lets get back to that one later Jan 20 11:15:03 <avalanche123> I opened it up Jan 20 11:15:05 <naderman> so topic is unicorns Jan 20 11:15:06 <Seldaek> well, I think we know what it is? Jan 20 11:15:06 <everzet> angry unicorn is great Jan 20 11:15:06 <pgodel_work> refresh worked Jan 20 11:15:12 <lsmith> ah ok Jan 20 11:15:14 * devilp (~email@example.com) has joined #symfony-dev Jan 20 11:15:16 <avalanche123> refresh... Jan 20 11:15:17 <cranberyxl> unicorns fart rainbows Jan 20 11:15:18 <lsmith> so lets keep going .. fabpot .. Jan 20 11:15:21 <henrikbjorn> We need to define best practices and reflect them in init:bundle Jan 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 Jan 20 11:16:01 <jmikola|w> beberlei: yes, there was some mailing list discussion about this within the last day i think Jan 20 11:16:03 <fabpot> yeah, I think that we are now free to dicuss the naming conventions again Jan 20 11:16:03 * rande (~Adium@darkstar2.fullsix.com) has left #symfony-dev Jan 20 11:16:14 <fabpot> I can send a new topic about that now Jan 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 Jan 20 11:16:41 <fabpot> for assets, it's exactly as before Jan 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 Jan 20 11:16:51 <naderman> fabpot: will you adjust the sandbox autoload.php to have /vendor/ or /src/ as fallbacks? Jan 20 11:16:54 <Seldaek> ok, so you refer to bundles by their getName() value Jan 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 Jan 20 11:17:23 <fabpot> naderman: quite possible, yes Jan 20 11:17:32 <fabpot> Seldaek: the getName() method is gone Jan 20 11:17:34 <beberlei> jmikola|w: fabien committed a "getParent()" approach for that just now Jan 20 11:17:41 <fabpot> the name is just the short class name Jan 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 Jan 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 Jan 20 11:17:59 <fabpot> naderman: yes, and Symfony2 does not really care Jan 20 11:18:07 <jmikola|w> beberlei: but would my App's version of the bundle i override be named FOSUserBundle? (for instance?) Jan 20 11:18:15 <jmikola|w> even though it's not in the FOS namespace but my own? Jan 20 11:18:35 <beberlei> jmikola|w: no your app is named as you want, "MyAppBundle" and it has a getParent() that says FOSUserBundle Jan 20 11:18:37 <jmikola|w> naderman: ah, i didn't catch that third-party bundles go in /vendor Jan 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 Jan 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/ Jan 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 Jan 20 11:19:07 <naderman> jmikola|w: re: naming your bundle FOSUserBundle, no why would you? you just return 'FOSUserBundle' in getParent() Jan 20 11:19:16 <jmikola|w> naderman: got it Jan 20 11:19:30 <fabpot> beberlei: support is possible Jan 20 11:19:31 <naderman> jmikola|w: it's been in discussion on the mailinglist for a bit recently Jan 20 11:19:42 <fabpot> beberlei: getParent() can just return an array of parents Jan 20 11:19:52 <fabpot> beberlei: that's easy to implement, but do we want that? Jan 20 11:20:09 <naderman> jmikola|w: the question was whether there was a point in keeping 3rd party Bundles somewhere other than libraries Jan 20 11:20:10 <beberlei> not sure, but people are going to ask why they cant to do it Jan 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? Jan 20 11:20:19 * henrikbjorn has quit (Ping timeout: 276 seconds) Jan 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? Jan 20 11:20:24 <jmikola|w> beberlei: are you concerned about overhead of creating bundles to override one resource at a time? Jan 20 11:20:27 <Seldaek> fabpot: that seems not to be an improvement in performances compared to the bundle dir approach Jan 20 11:20:29 <beberlei> Seldaek: inheritanc eonly works the other way around Jan 20 11:20:37 <fabpot> Seldaek: performance is better now Jan 20 11:20:42 <avalanche123> then I could define App:Controller:view.twig parameter with wome other value Jan 20 11:20:46 <avalanche123> *with Jan 20 11:20:48 * henrikbjorn (~firstname.lastname@example.org) has joined #symfony-dev Jan 20 11:20:50 <Seldaek> fabpot: so if you wanna override a bundle you have to copy ALL assets from it? Jan 20 11:20:53 * wSuFF_ (~email@example.com) has joined #symfony-dev Jan 20 11:20:57 * jmikola|w kills avalanche123 Jan 20 11:21:01 <fabpot> Seldaek: no, just the one you want to override Jan 20 11:21:10 <fabpot> it's exactly like what we have today Jan 20 11:21:13 <Seldaek> fabpot: yeah, otherwise it falls back to the parent path, taht's what I'm saying Jan 20 11:21:23 <lsmith> which fyi doesnt work for symlink Jan 20 11:21:23 <Seldaek> but if you do multiple inheritance, you'd have to check many parent paths Jan 20 11:21:27 <naderman> so if you have multiple paths it's not just "fallback" Jan 20 11:21:27 <Seldaek> so it'd become very slow Jan 20 11:21:40 <naderman> *multipl eparents Jan 20 11:21:43 <fabpot> Seldaek: but most of the time, you just have one parent and one child Jan 20 11:21:55 <fabpot> I don't see why you would want several parents Jan 20 11:22:04 <fabpot> you get a third-party bundle and you extend it Jan 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 Jan 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 ? Jan 20 11:22:27 <beberlei> AppFOSUserBundle? Jan 20 11:22:29 <lsmith> beberlei: it has a different vendor namespace Jan 20 11:22:33 <fabpot> beberlei: each bundle must have a different and unique name Jan 20 11:22:38 <Stof> what would be the way to get an overrided template ? the child name or the parent name ? Jan 20 11:22:40 <Seldaek> beberlei: you name it AppUserBundle and return FOSUserBundle in getParent Jan 20 11:22:42 <fabpot> name == short class name Jan 20 11:22:46 <beberlei> ah yeah probably Jan 20 11:22:47 <lsmith> src/FOS/UserBundle src/MyVendorNS/UserBundle Jan 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 Jan 20 11:23:24 <avalanche123> I was just proposing to modify renderer to look them up in DIC first Jan 20 11:23:32 <avalanche123> not changing existing rendering Jan 20 11:23:58 <Stof> I think calling FOSUserBundle:User:show.html.twig should look for child bundles, not the opposite Jan 20 11:24:11 <beberlei> isnt that how it works? Jan 20 11:24:18 <jmikola|w> Stof: this seems like an issue of late-static binding :) Jan 20 11:24:37 <Stof> it is not what has been suggested just before Jan 20 11:24:38 <beberlei> how would a bundle developer know what name the child has? Jan 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? Jan 20 11:25:03 <fabpot> ok, let me explain Jan 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? Jan 20 11:25:10 <fabpot> You have bundle A Jan 20 11:25:13 <fabpot> B extends A Jan 20 11:25:27 <lsmith> just FYI .. there is 5 more minutes on this time box Jan 20 11:25:29 <fabpot> So, when you use A:foo.html.twig, Symfony2 will look for the template in B, then A Jan 20 11:25:36 <beberlei> yah Jan 20 11:25:40 <Stof> ok Jan 20 11:25:41 <jmikola|w> fabpot: any concern if there was a C that also extended A? Jan 20 11:25:46 <beberlei> what if you do B:foo.html.twig? Jan 20 11:25:47 <jmikola|w> or is that an unsupported edge case Jan 20 11:25:52 <naderman> jmikola|w: that behaviour is undefined Jan 20 11:25:53 <fabpot> If C extends A, you will have an exception Jan 20 11:25:58 <naderman> Seldaek suggested to throw an exception Jan 20 11:25:59 <naderman> ah Jan 20 11:25:59 <Stof> jmikola|w: is it unsupported Jan 20 11:26:00 <beberlei> jmikola|w: throws exception Jan 20 11:26:09 <fabpot> but C can extends B and B extend A Jan 20 11:26:19 <jmikola|w> right, that sounds reasonable then Jan 20 11:26:27 <fabpot> have a look at the unit tests Jan 20 11:26:37 <jmikola|w> beberlei: i'd think B would go directly to the extending bundle Jan 20 11:26:46 <jmikola|w> or possibly something that extended IT Jan 20 11:26:50 <beberlei> fabpot: is asking for "B:foo.twig.html" cascaded to the parents also? bi-directional inheritance? Jan 20 11:26:53 * bschussek (~firstname.lastname@example.org) has left #symfony-dev Jan 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 Jan 20 11:26:56 <fabpot> tests/Symfony/Tests/Component/HttpKernel/KernelTest.php Jan 20 11:27:03 <fabpot> beberlei: nope Jan 20 11:27:04 <Stof> beberlei: seems weird Jan 20 11:27:09 <beberlei> yes i know Jan 20 11:27:11 <beberlei> just asking Jan 20 11:27:25 <beberlei> *preparing zeh pop quiz* :) Jan 20 11:28:00 * nielsie has quit (Ping timeout: 264 seconds) Jan 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. Jan 20 11:28:26 * rande (~Adium@darkstar2.fullsix.com) has joined #symfony-dev Jan 20 11:28:44 <fabpot> Seldaek: I think it's pretty simple to explain in the doc, much easier than the current namespace prefixes Jan 20 11:28:54 <lsmith> ok .. next topic then .. Jan 20 11:28:55 <lsmith> Change option naming convention to camelcase : http://bit.ly/hEUyFG Jan 20 11:28:56 <Seldaek> fabpot: yeah fair enough :) Jan 20 11:29:30 <jmikola|w> looks like bernhard dropped out Jan 20 11:29:33 <Seldaek> so, changing all options everywhere except in command line stuff to camelCase.. +1/-1 ? Jan 20 11:29:41 <henrikbjorn> -1 Jan 20 11:29:48 * srohweder has quit (Quit: Lost terminal) Jan 20 11:29:50 <Seldaek> I already mentionned the problem before with routing params leaking into php vars which were awkward Jan 20 11:29:55 <avalanche123> I don't mind as long as its consistent everywhere Jan 20 11:30:11 <jmikola|w> are routing params a concern? that's entirely up to the developer afaik Jan 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 Jan 20 11:30:23 <jmikola|w> unlike core things like constraints or form options Jan 20 11:30:30 <avalanche123> well they sould be comel-cased as they are used in PHP too Jan 20 11:30:34 <Seldaek> jmikola|w: well, if we change we change it all.. Jan 20 11:30:35 <avalanche123> *camel Jan 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 :( Jan 20 11:30:43 <henrikbjorn> Also command Jan 20 11:30:43 <lsmith> what would this all cover? how do we deal with DIC parameters that get send to services? Jan 20 11:30:47 <henrikbjorn> All or nothing Jan 20 11:30:59 <avalanche123> henrikbjorn, fabpot +1 Jan 20 11:31:02 <naderman> camelCase in xml isn't even that uncommon Jan 20 11:31:03 <lsmith> are they camelcase in the DIC? which wouldnt fly well in XML Jan 20 11:31:08 <naderman> so I think that's alright Jan 20 11:31:18 <henrikbjorn> Lsmith they would be funny looking and camelcase sucks for parameters Jan 20 11:31:40 <lsmith> i just cant bare any more of this - to _ conversion code in extensions Jan 20 11:31:43 <avalanche123> so now instead of doctrine_odm.mongodb: we would have doctrineOdm.mongodb: ? Jan 20 11:31:46 <lsmith> it drives me nuts to read it Jan 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 Jan 20 11:31:52 <avalanche123> in the yaml app config Jan 20 11:32:08 <lsmith> and its a source for bugs for different config formats .. Jan 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 Jan 20 11:32:10 <henrikbjorn> Avalanche123 yeah Jan 20 11:32:15 <lsmith> so what ever gets rid of that .. i would be +1000 Jan 20 11:32:16 <henrikbjorn> Which sucks Jan 20 11:32:34 <lsmith> jmikola|w: i think we have been sticking to ucfirst() for acronyms in many places Jan 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 Jan 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 Jan 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 Jan 20 11:33:36 <lsmith> how do we go about changing this? Jan 20 11:33:42 <lsmith> one bundle at a time? Jan 20 11:33:59 <henrikbjorn> Was i voted for? Jan 20 11:34:03 <lsmith> it will break many open pull requests Jan 20 11:34:05 <henrikbjorn> It* Jan 20 11:34:13 * unknownbliss (~unknownbl@unaffiliated/unknownbliss) has joined #symfony-dev Jan 20 11:34:14 <naderman> Seldaek: acronyms with only one uppercase letter is already being used though, no? Jan 20 11:34:16 <lsmith> henrikbjorn: nope .. Jan 20 11:34:20 <fabpot> lsmith: it will break EVERYTHING Jan 20 11:34:23 <beberlei> camel case in xml? ieeeks! Jan 20 11:34:23 * webPragmatist (~webby@unaffiliated/webpragmatist) has left #symfony-dev Jan 20 11:34:24 <henrikbjorn> It will break all apps Jan 20 11:34:33 <lsmith> yeah Jan 20 11:34:44 <jmikola|w> forgive me if this was answered, but wasn't bernhard mostly referring to validator/forms? Jan 20 11:34:45 <avalanche123> yeah, seems very messy, will look much more like java Jan 20 11:34:54 <beberlei> i thought it was about camel case in php Jan 20 11:34:56 <jmikola|w> or those configs really comparable to DIC stuff and routing? Jan 20 11:34:56 * webPragmatist (~email@example.com) has joined #symfony-dev Jan 20 11:34:56 * webPragmatist has quit (Changing host) Jan 20 11:34:56 * webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev Jan 20 11:34:57 <beberlei> not in yml and xml Jan 20 11:35:06 <lsmith> seeing beberlei's heart attack .. how do we deal with Doctrine? Jan 20 11:35:13 <naderman> beberlei: it's about avoiding to have to convert stuff now ;-) Jan 20 11:35:15 <beberlei> i dont comply! Jan 20 11:35:16 <avalanche123> jmikola|w for consistency, we would change all or nothing I think Jan 20 11:35:53 <beberlei> if its about yml and xml config also i say no Jan 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) Jan 20 11:36:07 <beberlei> if people cant think in contexts then its their problem Jan 20 11:36:08 <henrikbjorn> Beberlei same its nasty Jan 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 ? Jan 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 Jan 20 11:36:16 <Stof> beberlei: the problem is that some parameters are defined in XML and used in PHP (for routing for example) Jan 20 11:36:20 <bobthecow> beberlei: +1 Jan 20 11:36:22 <Stof> so they are in both worlds Jan 20 11:36:33 <jmikola|w> fabpot: +1 Jan 20 11:36:34 <avalanche123> after thinking about it more, I am against camel case in yml and xmx Jan 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 Jan 20 11:36:49 <henrikbjorn> Jmikola xml and html uses - which yaml can use too Jan 20 11:36:51 <mvrhov> so why don't we normailize everything? Jan 20 11:36:59 <beberlei> expensive Jan 20 11:37:01 <mvrhov> to camelcase before using it Jan 20 11:37:01 <bobthecow> zend has a great library for converting between underscored and camelcase. Jan 20 11:37:03 <beberlei> and wasted cpu time Jan 20 11:37:05 <jmikola|w> i'm leaning against camel case in general though Jan 20 11:37:36 <fabpot> bobthecow: lol Jan 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 _ Jan 20 11:38:13 <naderman> library o_O Jan 20 11:38:16 <bobthecow> could make a camelcase pass to normalize imported configs. Jan 20 11:38:35 <Seldaek> converting automatically will lead to countless WTFs Jan 20 11:38:38 <Seldaek> let's not go there Jan 20 11:38:48 <bobthecow> not if there's a well defined conversion algorithm. Jan 20 11:38:51 <Seldaek> even if it's fast I don't care Jan 20 11:39:02 <Seldaek> you type a value in your config, you expect the same in your php code Jan 20 11:39:27 <avalanche123> bobthecow, in the code you would have to call $container->getParameter('camelCasedName') still Jan 20 11:39:39 <bobthecow> ooh. true. Jan 20 11:39:50 <fabpot> I think everything has been said Jan 20 11:40:02 <fabpot> and it looks like we won't change the current conventions anytime soon Jan 20 11:40:18 <Seldaek> yeah, let's see what bernhard thinks after reading the log :) Jan 20 11:40:23 <avalanche123> :) Jan 20 11:40:39 <lsmith> ok Jan 20 11:40:41 * nielsie (firstname.lastname@example.org) has joined #symfony-dev Jan 20 11:40:48 <lsmith> next topic Jan 20 11:41:05 <lsmith> this one only has 3 votes .. but thats because i screwed up and a few votes got deleted Jan 20 11:41:05 <lsmith> load extension configs once: http://bit.ly/hHGeb0, http://bit.ly/hhGtmN Jan 20 11:41:14 <lsmith> johanness created a branch Jan 20 11:41:17 <jmikola|w> https://github.com/schmittjoh/symfony/tree/loadConfigOnce Jan 20 11:41:24 <lsmith> right Jan 20 11:41:29 <lsmith> this is only the first step of course Jan 20 11:41:29 <jmikola|w> fabpot: did you get my github response about this? Jan 20 11:41:38 <lsmith> we will want to add smarter merging algo's Jan 20 11:41:40 <fabpot> jmikola|w: hmmm, not sure Jan 20 11:41:45 * iAsteris_ has quit (Quit: Computer has gone to sleep.) Jan 20 11:41:50 <lsmith> rather than just replicating the existing approach of calling the load methods for each config Jan 20 11:41:59 <jmikola|w> so lsmith alerted me to johannes work after our convo tuesday (when you asked about me doing this) Jan 20 11:42:00 * wSuFF_ has quit (Quit: Computer has gone to sleep.) Jan 20 11:42:17 <fabpot> lsmith: Don't even think about merging algo. Merging is the responsibility of each extension. Jan 20 11:42:17 <jmikola|w> johanness was in support of not having a separate merge method, as not everyone will need it Jan 20 11:42:27 <lsmith> fabpot: thats what i mean Jan 20 11:42:32 <jmikola|w> so he passes all the configs to the load() method Jan 20 11:42:44 <lsmith> the above patch updates all extensions to loop over all configs and call the load method Jan 20 11:42:53 <lsmith> which is exactly the behavior we have now Jan 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? Jan 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 Jan 20 11:43:06 <lsmith> and then in step two we update the extensions to do something intelligent Jan 20 11:43:16 <fabpot> lsmith: yes, that was not what we decided last time IIRC Jan 20 11:43:19 <avalanche123> I agree with fabpot, let's table it for later discussion Jan 20 11:43:23 <lsmith> fabpot: the main question is if we agree on the API Jan 20 11:43:34 <lsmith> aka the load method gets an array with all the configs Jan 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 Jan 20 11:44:12 <Stof> fabpot: lsmith is talking about each core extension, not about creating a generic load method Jan 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 Jan 20 11:44:13 <lsmith> basically imho the patch is ready to be pulled Jan 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 Jan 20 11:44:35 <lsmith> Seldaek: if at all .. the default merge method would return the last Jan 20 11:44:38 <lsmith> but its not possible Jan 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 Jan 20 11:44:45 <lsmith> since you can have multiple load methods Jan 20 11:44:51 <lsmith> you need multiple merge methods Jan 20 11:44:53 <Seldaek> lsmith: ah right Jan 20 11:44:57 <Seldaek> nvm then Jan 20 11:45:06 <lsmith> which means a default is impossible without a method exists check Jan 20 11:45:12 <lsmith> which is why i think a single load method is the way to go Jan 20 11:45:15 <lsmith> no merge method Jan 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 Jan 20 11:45:30 <Stof> yeah, johannes patch seems good. Jan 20 11:45:35 <lsmith> last time IIRC we wanted a merge method .. Jan 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 Jan 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) Jan 20 11:46:05 <lsmith> jmikola|w: just unit test the protected one via the public one Jan 20 11:46:09 <lsmith> or use proxies .. Jan 20 11:46:21 <lsmith> or for most cases i dont think the load will do much of anything fancy Jan 20 11:46:25 <Stof> then the core extensions will need to be refactored to be sure the merging is the best used Jan 20 11:46:27 <jmikola|w> is that what we'll do for core unit tests, though? Jan 20 11:46:31 <fabpot> Seldaek: true Jan 20 11:46:33 <lsmith> so i wouldnt even bother with unit (maybe functional tests) Jan 20 11:46:33 * AlHornair has quit (Quit: Ex-Chat) Jan 20 11:46:39 <jmikola|w> lsmith: agreed, the merging logic is essentially, at some point in the config block, you just override keys Jan 20 11:47:21 <beberlei> lsmith: i disagree Jan 20 11:47:21 <lsmith> ok .. sounds like the branch is good and the next step is updating each extension Jan 20 11:47:29 <jmikola|w> so, if johanness' branch can get into core, i will take on porting over FrameworkExtension Jan 20 11:47:34 <beberlei> the merging is pretty complicated in case of security or doctrine extension Jan 20 11:47:39 <beberlei> i want to test it withought hickups Jan 20 11:47:39 <jmikola|w> I assume johanness would do Security - but we can coordinate on the mailing list Jan 20 11:47:42 <lsmith> beberlei: unit test junkies need to know how to do proxies Jan 20 11:47:58 <avalanche123> beberlei +1 this method should be explicit and public Jan 20 11:48:09 <beberlei> has nothing to do with junkie, i want to stuff two arrays in get one array out Jan 20 11:48:17 <beberlei> what proxy btw? Jan 20 11:48:26 <beberlei> to detect hundrets of calls to the container? Jan 20 11:48:36 <lsmith> beberlei: to test protected methods in unit tests you need to create a proxy with adjusted visibility Jan 20 11:48:42 <lsmith> anyway .. off topic Jan 20 11:48:50 <beberlei> ah that ugly thing :) Jan 20 11:48:52 <avalanche123> lsmith if you are testing protected methods, you're doing it wrong:) Jan 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 Jan 20 11:48:55 <Stof> beberlei: johannes patch does exactly what is actually done in the extension by loading each config separatlty Jan 20 11:48:56 <naderman> lsmith: hence the suggestion not to have it protected Jan 20 11:49:00 * henrikbjorn has quit (Ping timeout: 264 seconds) Jan 20 11:49:06 * daniel123 (~email@example.com) has joined #symfony-dev Jan 20 11:49:10 <lsmith> but its not called from the outside Jan 20 11:49:20 <lsmith> the load method is .. and then it does whatever it pleases Jan 20 11:49:26 * henrikbjorn (~firstname.lastname@example.org) has joined #symfony-dev Jan 20 11:49:34 <Stof> and it is not even mandatory if it uses a true merging Jan 20 11:49:37 <lsmith> it can just do $config = array_pop($configs) Jan 20 11:49:42 <lsmith> and not bother with a separate method at all Jan 20 11:49:50 <avalanche123> that I agree with Jan 20 11:50:00 <lsmith> so why make two methods public? Jan 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? Jan 20 11:50:05 * Garfield-fr has quit (Quit: ⏏) Jan 20 11:50:08 <lsmith> there is only a need for one Jan 20 11:50:09 <beberlei> jmikola|w ok you are right Jan 20 11:50:10 <avalanche123> beberlei, I think if merging gets too complicated, you could extract a Merger... dunno Jan 20 11:50:19 <beberlei> virgin container + asserting there is good Jan 20 11:50:32 <lsmith> simple extension dont need one, complex one will have one Jan 20 11:50:33 <lsmith> yes Jan 20 11:50:45 <lsmith> ok .. we only have 10 minutes .. Jan 20 11:50:51 <lsmith> lets go to the next topic, ok? Jan 20 11:50:54 <avalanche123> sure Jan 20 11:50:55 <lsmith> Request changes: http://bit.ly/eobRAH Jan 20 11:51:02 <lsmith> avalanche123: take it away Jan 20 11:51:06 <avalanche123> hi Jan 20 11:51:13 <avalanche123> so basically here is my point of view Jan 20 11:51:23 <avalanche123> request -> parameters -> controller -> parameters -> view Jan 20 11:51:31 <avalanche123> for requests with request body Jan 20 11:51:45 <avalanche123> the body needs to be parsed into $request arguments Jan 20 11:52:08 <avalanche123> that way you could have the same controller handle json and form requests Jan 20 11:52:13 <avalanche123> *ideally* Jan 20 11:52:33 <avalanche123> so then we would have request body parsers (whatever you call them) Jan 20 11:52:39 <henrikbjorn> I dont get that Jan 20 11:52:48 <avalanche123> form post looks like Jan 20 11:52:49 <henrikbjorn> Why cant it do that now? Jan 20 11:52:59 <avalanche123> key=val&key2=val Jan 20 11:53:07 <jmikola|w> henrikbjorn: currently it sets request property based on $_POST Jan 20 11:53:14 <avalanche123> henrikbjorn right now request gets whatever is in $_POST Jan 20 11:53:27 <avalanche123> but for json and xml requests, that array is empty Jan 20 11:53:31 <kriswallsmith> how would you read the request body? Jan 20 11:53:36 <jmikola|w> so avalanche123 is proposing changing the default request value based on the content-type of the http request Jan 20 11:53:38 <avalanche123> as you post a jxon object Jan 20 11:54:02 * kertz_ (~email@example.com) has joined #symfony-dev Jan 20 11:54:11 <avalanche123> form post has content type of application/x-*www-form*-*urlencoded* Jan 20 11:54:12 <naderman> kriswallsmith: http_get_request_body() ? Jan 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 Jan 20 11:54:23 <avalanche123> and json post would be application/json Jan 20 11:54:44 <avalanche123> so you could chose how to process request body based on content-type Jan 20 11:54:44 <igorw> naderman: that's pecl Jan 20 11:54:48 <naderman> oh Jan 20 11:55:06 <avalanche123> but to do that we would have to change how request is initialized Jan 20 11:55:08 <Seldaek> kriswallsmith: you can file_get_contents('php://input') as well to read the body Jan 20 11:55:12 <henrikbjorn> Is this in correspondance with the http protocol? Jan 20 11:55:14 <fabpot> avalanche123: we already had a pull request for that, and it was rejected as too magic was involved Jan 20 11:55:21 * tecbot has quit () Jan 20 11:55:22 <fabpot> so it should be done outside of the Request class Jan 20 11:55:31 <avalanche123> fabpot, I agree Jan 20 11:55:40 <avalanche123> so my point was to make Kernel populate empty request Jan 20 11:55:47 <fabpot> but, I'm in favor of having something to deal with that Jan 20 11:55:50 <avalanche123> instead of request populating itself Jan 20 11:56:02 <jmikola|w> avalanche123: i think request can still default to $_POST though, right? Jan 20 11:56:05 <avalanche123> so the request class would be very similar to response class Jan 20 11:56:16 <jmikola|w> or would that default value be removed entirely Jan 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 Jan 20 11:56:29 <avalanche123> it would be registered on application/x-*www-form*-*urlencoded* request type Jan 20 11:56:33 * kertz has quit (Ping timeout: 240 seconds) Jan 20 11:56:33 * kertz_ is now known as kertz Jan 20 11:56:35 <fabpot> avalanche123: that's a small change and seems reasonnable. You need to check that it does not break anything. Jan 20 11:56:35 <avalanche123> and the multipart one Jan 20 11:56:38 <mvrhov> Seldaek, weren't there some problems with php://input ? Jan 20 11:56:46 <fabpot> naderman: yes Jan 20 11:56:57 <avalanche123> fabpot, yeah, I will start on it and ping you with questions if anything Jan 20 11:57:09 <Seldaek> mvrhov: it can just be read once, but that's it Jan 20 11:57:20 <avalanche123> and we don't need more than once Jan 20 11:57:23 <lsmith> ok .. last topic spills over from this one .. Parameter converters: http://bit.ly/hgPPbo Jan 20 11:57:23 <Seldaek> mvrhov: well, only once on SOME SAPIs, but it's available everywhere Jan 20 11:57:30 <fabpot> Seldaek: but the request already take care of that Jan 20 11:57:31 <avalanche123> me again:) Jan 20 11:57:42 <avalanche123> I think it was clear what it was about to everyone on the ml Jan 20 11:57:43 <Seldaek> fabpot: yeah sure, I was just answering kriswallsmith's question : Jan 20 11:58:09 <avalanche123> basically making explicit registration of parameter converter per parameter would allow for bi-directional conversion Jan 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 Jan 20 11:58:42 <avalanche123> that would take parameters: into account Jan 20 11:58:44 <beberlei> is that a necessary use-case? Jan 20 11:59:00 <avalanche123> beberlei I dunno, seems useful Jan 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 Jan 20 11:59:07 * ornicar (~firstname.lastname@example.org) has joined #symfony-dev Jan 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 Jan 20 11:59:23 <avalanche123> I am not familiar with that:) Jan 20 11:59:26 <fabpot> beberlei: +1 Jan 20 11:59:32 <fabpot> avalanche123: trust me Jan 20 11:59:34 <jmikola|w> avalanche123: that's what i was talking to you about the other day Jan 20 11:59:42 <avalanche123> I get your point:) Jan 20 11:59:49 <henrikbjorn> I think maybe we should slim them down and not send the request with the apply method? Jan 20 12:00:25 <kriswallsmith> i think you can only read from php://input once Jan 20 12:00:28 <Seldaek> avalanche123: I think that thing could be built on top of controllers with annotations (at least for the deserializing) Jan 20 12:00:37 <naderman> kriswallsmith: yes, see fabpot's answer above Jan 20 12:00:55 <avalanche123> Seldaek, yeah, I will have to see about that Jan 20 12:01:01 <fabpot> Seldaek: that's what I started in FrameworkExtraBundle Jan 20 12:01:15 <avalanche123> fabpot, should we get rid of them period? Jan 20 12:01:15 <Seldaek> yup, I think it's not something that needs to be in core Jan 20 12:01:22 <Seldaek> and we should forget about it until final is out :) Jan 20 12:01:33 <fabpot> Seldaek: hehe, +1 Jan 20 12:01:49 <henrikbjorn> Maybe we should moe them back out of core? Jan 20 12:01:52 <fabpot> avalanche123: I think we need to work on more important features for now Jan 20 12:01:52 <Seldaek> there's enough other things to tend to I guess Jan 20 12:02:06 <avalanche123> fabpot agreed Jan 20 12:02:14 <Seldaek> fabpot: I'll submit that serializer thingy this weekend hopefully.. at least a basic version for review Jan 20 12:02:16 <fabpot> henrikbjorn: yeah, that's what I was thinking Jan 20 12:02:26 <henrikbjorn> Lets do that Jan 20 12:02:31 <avalanche123> henrikbjorn +1 Jan 20 12:02:38 <lsmith> ok .. Jan 20 12:02:43 <lsmith> guess time is up and stuff Jan 20 12:02:53 <beberlei> yay to the alc now Jan 20 12:02:55 <beberlei> err Jan 20 12:03:00 <lsmith> thx for everybody talking so much ... summary will be a ton of work :-/ Jan 20 12:03:04 <henrikbjorn> Fabpot should it still rely on annotations in frameworkextra? Jan 20 12:03:12 <avalanche123> thanks for great discussion Jan 20 12:03:13 <beberlei> lsmith: we know how to make you happy Jan 20 12:03:31 <fabpot> henrikbjorn: it already does not rely on annotations, except if you want to pass parameters Jan 20 12:03:35 <lsmith> i need a padawan for this stuff Jan 20 12:03:46 <weaverryan> lsmith: Thanks for doing the summary though - I missed almost all of this meeting Jan 20 12:03:48 <beberlei> i thought that was Seldaek ? :) Jan 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 Jan 20 12:03:59 <jmikola|w> Seldaek: i'm doing it now :)