The current approach to asset handling is limited and doesn't lend it self well to how twig works. Furthermore nowadays most developers try to combine+minify their jss/css into a single file. Therefore the aim is to port python's webassets to Symfony2.
Bundle config merging
It was decided that extension loading will be changed that first all configs will be collected and then passed to the load() method, which can then handle merging and loading. Jeremy offered to take on this task.
Adding validators to Doctrine*Bundle
According to Jeremy gordonslondon and Bulat are willing to donate their Doctrine unique validators under the MIT and it was agreed that their work would be integrated into the respective Doctrine Bundles.
roadmap until RC1
Twig RC1 will be released soon. Fabien will work out a roadmap over the weekend, which can then be discussed on the list or at the next IRC meeting. The goal is to focus on one component per week and stabilize the API. Currently the Security/ACL is probably the most worrisome part. RC1 is planed for symfony live SF in February with the stable release in Paris is March. Fabien really wants to make it, but acknowledges if its not possible we will not release in March.
Establishing bundle dependencies
There was agreement that some sort of manifest file needs to be established that Bundles can use. There should be console integration for an installer/updater. For now Pyrus seems the most promising base. Lukas promised to try and get in contact with the Pyrus development team. Benjamin also raised the point that this should also integrate into a service like symfony2bundes.org and pearhub.
RFC: Naming issues
It was agreed that config's should prefer underscore in all formats. Also Jordi will create pull to rename the Tests directory to Test.
Jan 06 11:00:22 <lsmith> ok .. meeting time .. Jan 06 11:00:32 <lsmith> including assets: http://bit.ly/gJyDur Jan 06 11:00:40 <lsmith> that seems like the number one topic Jan 06 11:01:05 <lsmith> fabpot: can you maybe give us some pointers on your thoughts on this? Jan 06 11:01:54 <fabpot> the old implementation of the helpers/tags has serious limitations Jan 06 11:02:21 <fabpot> basically, it cannot work properly with Twig (due to the order in which templates and their parents are rendered) Jan 06 11:02:32 <fabpot> and there is no way to add a css/js in an included file Jan 06 11:02:56 <fabpot> so, the only way to use them is barely useful as using direct HTML tags is more or less equivalent Jan 06 11:03:09 <fabpot> except for the fact that the helper/tag check for uniqueness Jan 06 11:03:21 <fabpot> but there is another reason Jan 06 11:03:27 * bulatshakirzyano (~email@example.com) has joined #symfony-dev Jan 06 11:03:29 <Seldaek> do you think a solution can be found to work without a response filter? I mean to output the aggregated css includes in the <head> Jan 06 11:03:33 <fabpot> and this is realted to how we manage css/js nowadays Jan 06 11:04:02 <fabpot> instead of trying to include just the needed js/css files for a given page (which was the goal of the tags/helpers) Jan 06 11:04:18 <fabpot> it is much better to create 'packages" of js/css to allow minification/compilation/... Jan 06 11:04:28 <weaverryan> yes :) Jan 06 11:04:35 * ce_afk is now known as cescalante Jan 06 11:04:43 <fabpot> so, I'd rather work on that, instead of keeping the flawed approach of symfony 1 Jan 06 11:04:47 <fabpot> so, here is the plan Jan 06 11:04:49 <Seldaek> yeah I never liked the 20 js includes on one page Jan 06 11:04:59 <fabpot> we won't have anything by default in Symfony2 core Jan 06 11:05:14 <fabpot> we use an existing PHP library that does the work for us (or we create one if needed) Jan 06 11:05:28 <fabpot> we create a small bundle to integrate that into the PHP templating system and Twig Jan 06 11:05:44 <fabpot> one library that I really like a lot is this one in Python: http://elsdoerfer.name/docs/webassets/ Jan 06 11:06:00 <fabpot> it does exactly what we need and to me, they are the right balance between complexity and features Jan 06 11:06:25 <fabpot> I've already received quite a few proposal from people to work on that Jan 06 11:06:34 <fabpot> so, we need some coordination here to avoid duplicate work Jan 06 11:06:50 <rande> I can port the swCombinePlugin into a symfony2 bundle Jan 06 11:07:32 <Seldaek> I'd prefer a good ol' rewrite than a port of some old plugin, but I have no idea what swCombinePlugin does Jan 06 11:07:47 <lsmith> https://github.com/FriendsOfSymfony/AssetProcessorBundle and https://github.com/tecbot/AssetPackagerBundle Jan 06 11:07:52 <rande> the swCombinePlugin can merge css file (included merge @import statement, and resolve image path) Jan 06 11:08:09 <weaverryan> hence the need to coordinate - we can't have the sf1 situation where we have 10 solutions Jan 06 11:08:10 <rande> it also add an version number inside all url Jan 06 11:08:11 <lsmith> i think both are still in their early stages Jan 06 11:08:21 <weaverryan> the most important thing is to get organized - the details can be figured out from there Jan 06 11:08:26 <fabpot> Im' with @Seldaek here. I really like webassets, so the solution should at least be as smart as this Python library Jan 06 11:08:41 <rande> it also non existant image defined into the css (to avoid 404 error) Jan 06 11:08:52 <fabpot> so you have been warned. I will only consider something on par with webassets Jan 06 11:09:09 <rande> swCombine can use different driver to optimize the css and js ... Jan 06 11:09:11 <fabpot> and I think porting webassets is just a matter of 2 or 3 hours of work Jan 06 11:10:02 <Seldaek> webassets seems nice indeed Jan 06 11:10:24 <lsmith> ok .. i would suggest that those interested to collaborate coordinate after the meeting on IRC and/or the mailinglist Jan 06 11:10:31 <lsmith> so i guess we can move to the next topic? Jan 06 11:10:33 <Seldaek> we can start with a webassets port and then add features from swCombinePlugin and others if they are missing Jan 06 11:10:42 <weaverryan> solid plan Jan 06 11:10:54 <lsmith> Bundle config merging: http://bit.ly/e4wDrl Jan 06 11:11:20 <rande> swCombine base lib look like webassets Jan 06 11:11:26 <lsmith> so right now if you config a bundle multiple times (say in config.yml and in config_dev.yml) Jan 06 11:11:34 <lsmith> the load method is actually called multiple times Jan 06 11:11:49 <lsmith> this is useful in order to set some additional parameters in dev/test Jan 06 11:12:01 <lsmith> however it makes the life of bundle authors a bit painful Jan 06 11:12:02 <Seldaek> rande: bring it up later again please, I want to have a look but let's not pollute the other topic now :) Jan 06 11:12:14 <jmikola|w> re: config merging is up to the developer of the bundle afaik... frameworkbundle does a good job of using isset judiciously to handle multiple calls safely Jan 06 11:12:18 <lsmith> so it was suggested that bundle extension should provide a merge method Jan 06 11:12:27 <lsmith> to merge those configs Jan 06 11:12:34 <lsmith> and then the extension load method is only called once Jan 06 11:12:40 <rande> Seldaek: yep sorry I realize this a bit too late ;) Jan 06 11:13:05 <johanness> jmikola|w: the idea is to have two separate methods for merging, and for loading Jan 06 11:13:14 <lsmith> so idea is just to make things harder to screw up or in other words easier Jan 06 11:13:17 <jmikola|w> i could imagine a merge method, even if it's smarter than array_merge(), causing trouble with incompatible settings Jan 06 11:13:39 <weaverryan> jmikola|w small point, but the isset's don't self-document well - it's not all that clear that they're there to avoid duplicate setup (at least it wasn't to me) Jan 06 11:13:46 <jmikola|w> you'd trade off for the difficulty of having to detect merge conflictsw Jan 06 11:13:47 <johanness> jmikola|w: the merge method has to be implemented by the developer Jan 06 11:13:49 <jmikola|w> weaverryan: fair point Jan 06 11:13:55 <fabpot> jmikola|w: we will never add automatic merging if that's what you suggest, just to split the current method in two methods Jan 06 11:14:28 <beberlei> adding a merge step before load would simplify the load methods alot Jan 06 11:14:31 <fabpot> I'm not sure it will ease anthing if we were to split the load method in two methods Jan 06 11:14:32 <jmikola|w> i realize the merge method is up to the developer - but i don't see how it'd be much different than configLoad() Jan 06 11:14:50 <fabpot> jmikola|w: I agree Jan 06 11:14:57 <lsmith> jmikola|w: you would have one method just dedicated to merging .. Jan 06 11:15:00 <jmikola|w> if it's really separating code that otherwise would all get lumped into load(), then that's an obvious benefit Jan 06 11:15:03 <beberlei> if you design your configs right maybe array_merge_recursive should even be a default? since if you dont use null or 0 as keys you dont have to care Jan 06 11:15:09 <fabpot> I think we need to refactor FrameworkBundle to see if if changes anything Jan 06 11:15:10 <jmikola|w> less monolithic functions, and easier to unit test Jan 06 11:15:20 <johanness> especially if you create dynamic services you don't now the names of services which have been created in a previous call Jan 06 11:15:23 <lsmith> and one dedicated to loading .. Jan 06 11:15:24 <fabpot> beberlei: no, this is the big mistake we made in symfony 1 Jan 06 11:15:28 <lsmith> also not knowing if you actually have the "final" config yet makes load harder Jan 06 11:15:35 <beberlei> currently its impossible and ugly and almost never done to test calls to *load() multiple times Jan 06 11:15:38 <johanness> you would have to iterate over all definitions to find them Jan 06 11:15:52 <beberlei> plus its very unintuitive how it works :) Jan 06 11:15:54 <johanness> and then do a clean up Jan 06 11:16:02 <fabpot> lsmith: you never know if you have the latest config Jan 06 11:16:10 <beberlei> hm ok Jan 06 11:16:28 <lsmith> how so? if we merge and only load once .. Jan 06 11:16:45 <lsmith> then your load always has the final config Jan 06 11:16:46 <fabpot> you only call load() once but merge() will be called n times Jan 06 11:16:52 <lsmith> fabpot: yes .. Jan 06 11:16:54 <lsmith> of course Jan 06 11:17:02 <johanness> can't the call to the merge method be delayed? Jan 06 11:17:04 <Seldaek> yes but in load you can make the assumption it's the one and only, and do stuff you wouldn't do now Jan 06 11:17:16 <johanness> until we have all config sections Jan 06 11:17:17 <fabpot> the changes in the DIC are very simple,so someone can probably try to split one or two config to see how it goes Jan 06 11:17:39 <fabpot> johanness: this is already the case in fact Jan 06 11:17:47 <fabpot> as the merge is done during freezing Jan 06 11:17:58 <fabpot> so, we can probably pass all the configs to the merge() method Jan 06 11:18:02 <lsmith> so it sounds to me .. the idea is not totally crazy .. and so someone should implement the necessary changes and port some core bundles to this approach and send a pull Jan 06 11:18:03 <fabpot> instead of calling it several times Jan 06 11:18:19 <jmikola|w> then would the load methods ultimately run at bundle boot time? Jan 06 11:18:20 <fabpot> that way, we can garantuee 1 call to load() and 1 call to merge() Jan 06 11:18:34 <lsmith> cool Jan 06 11:18:45 <jmikola|w> oh, merge would take multiple config arrays at once? Jan 06 11:18:46 <johanness> we wouldn't need to split them anymore Jan 06 11:18:49 * dustinwhittle (~firstname.lastname@example.org) has joined #symfony-dev Jan 06 11:18:54 <johanness> if it's only one call Jan 06 11:18:54 <fabpot> jmikola|w: yes Jan 06 11:18:56 <lsmith> johanness: correct :) Jan 06 11:18:59 <jmikola|w> neat Jan 06 11:19:07 <lsmith> but it would still be cleaner imho to do so Jan 06 11:19:08 <fabpot> who wants to work on this? Jan 06 11:19:22 <johanness> lsmith: not all bundles will need this Jan 06 11:19:34 <johanness> so it's just work in most cases to implemented two methods if one is fine Jan 06 11:20:02 <lsmith> well the default implementation just explodes if more than one array is passed Jan 06 11:20:16 <jmikola|w> i'll look into this Jan 06 11:20:22 <lsmith> and returns that one array otherwise Jan 06 11:20:24 <fabpot> jmikola|w: thanks Jan 06 11:20:24 <jmikola|w> if no one else is going to put up their hand :) Jan 06 11:20:35 <lsmith> ok .. then lets move on Jan 06 11:20:36 <lsmith> adding validators to Doctrine*Bundle: http://bit.ly/eNgIGi Jan 06 11:20:40 <jmikola|w> i think this was me Jan 06 11:20:45 <lsmith> yeah Jan 06 11:20:51 <jmikola|w> so, OpenSky has a bad habit of releasing code in AGPL :) Jan 06 11:21:00 <jmikola|w> including avalanche123's doctrine unique validators Jan 06 11:21:20 <jmikola|w> these are pretty essential validators; and gordon (i think that's his name) wrote an ORM version Jan 06 11:21:39 <jmikola|w> i think these would be good candidates to go to the ORM/ODM bundles, with common shared code in beberlei's abstract bundle Jan 06 11:21:45 * rooster has quit (Read error: Operation timed out) Jan 06 11:21:47 <jmikola|w> if avalanche123 and gordon are ok contributing the code Jan 06 11:21:55 <lsmith> https://github.com/search?q=doctrine+unique&type=Everything&repo=&langOverride=&start_value=1 Jan 06 11:21:56 <fabpot> yep, I think they need to be bundled with the Doctrine bundles Jan 06 11:21:57 <jmikola|w> and beberlei / jwage are ok Jan 06 11:22:13 <jmikola|w> gordonslondon, right Jan 06 11:22:40 <fabpot> looks like everybody is ok then Jan 06 11:22:44 <jmikola|w> ok, so i think this can be handled offline then Jan 06 11:22:50 <jmikola|w> next topic? :) Jan 06 11:22:54 <lsmith> roadmap until RC1 Jan 06 11:23:03 <beberlei> i am ok with the unique validators Jan 06 11:23:09 <jmikola|w> beberlei: thanks Jan 06 11:23:16 <beberlei> like if thats my decision :D Jan 06 11:23:27 <lsmith> thats the next topic .. i guess fabpot is the guy to start us off on that one Jan 06 11:23:55 <jmikola|w> 3 months of writing unit tests, yay Jan 06 11:23:56 <fabpot> first, I will release Twig 1.0RC1 probably tomorrow Jan 06 11:24:12 <lsmith> jmikola|w: its only 2 more months :-/ Jan 06 11:24:16 <fabpot> which means that Twig API is now finished Jan 06 11:24:19 <lsmith> or actually :-) Jan 06 11:24:29 <beberlei> if release is in march beta must be out of the door like very soon. otherwise we don't get enough feedback, the 1 year alpha/beta/rc phase for Doctrine allowed us LOTS of BC changes that were necessary from an architectural pov Jan 06 11:24:36 * rooster (~russ@2a02:c0:1002:100:f2de:f1ff:fe24:731d) has joined #symfony-dev Jan 06 11:24:39 <fabpot> that will help stabilize the TwigBundle, as it has changed a lot in the last few weeks Jan 06 11:24:58 <fabpot> beberlei: the plan was to release beta1 at the end of December Jan 06 11:25:08 <fabpot> I think we can release beta1 early next week Jan 06 11:25:10 <beberlei> ah ok, so final release will be april? :) Jan 06 11:25:19 <fabpot> RC1 during the San Francisco conference Jan 06 11:25:33 <fabpot> and final March 5th Jan 06 11:25:38 <lsmith> to me the only major missing feature before beta1 is rememberme Jan 06 11:25:40 <fabpot> during the hacking day Jan 06 11:25:45 <beberlei> as much as i want to see symfony2 stable, i would hate to see architectural flaws in the final also Jan 06 11:25:58 <Stof> lsmith: and the AdminBundle Jan 06 11:26:07 <Seldaek> fabpot: please don't rush it, I get the thing with sflive and all, but let's take the time we need and make sure we don't get stuck in maintenance hell for the next 5 years Jan 06 11:26:11 <fabpot> Stof: no, the admin bundle is not part of the core, so that's not a problem Jan 06 11:26:17 <lsmith> Stof: i dont think we should aim for an admin bundle for sf2 core stable .. Jan 06 11:26:19 <lsmith> it might happen Jan 06 11:26:26 <Stof> oh ok Jan 06 11:26:42 <lsmith> bernhard will be working at liip for a month starting end of january Jan 06 11:26:42 <fabpot> Seldaek: people expect Symfony2 in March. So, we need to be as close as possible to this date. Jan 06 11:26:46 <lsmith> working on admin generator stuff Jan 06 11:27:02 <lsmith> fabpot: i can also see us releasing RC1 in paris Jan 06 11:27:05 <fabpot> I don't want to rush, but people can be very bad when we miss our deadlines (unfortunately) Jan 06 11:27:16 <fabpot> here is the idea I have to stabilize Symfony2 Jan 06 11:27:20 <beberlei> fabpot: we sort of made people expect doctrine 2 for september and everyone understood when we said more time = better code :) Jan 06 11:27:21 <jmikola|w> fabpot: what are the testing goals? a certain % of code coverage via xdebug/phpunit? Jan 06 11:27:24 <Seldaek> fabpot: I get that, but I'd like to keep the BC breaks going as long as possible until march Jan 06 11:27:28 <fabpot> Each week, we work on one component to stabilize the API Jan 06 11:28:04 <beberlei> although we have lots more eyes on symfony2 than there were on doctrine2 Jan 06 11:28:12 <beberlei> and active contributors Jan 06 11:28:13 <fabpot> beberlei: I don't want to be rude, but the size of the community is not the same. And when I announced that the final release would be March 2011 instead of December 2010, I received a lot of complaints Jan 06 11:28:41 <beberlei> yah size of the community and active contributors is probably a factor here to allow for a faster schedule Jan 06 11:28:46 <Seldaek> fabpot: and you did than after publishing your home address too, not smart ;) Jan 06 11:28:53 <fabpot> If we think that we cannot release in March, we won't Jan 06 11:28:55 <lsmith> hehe Jan 06 11:29:08 <fabpot> but let's try to keep this schedule for now Jan 06 11:29:12 <fabpot> as I think this is still possible Jan 06 11:29:16 <lsmith> i think its possible .. but a lot of hard work .. Jan 06 11:29:27 <lsmith> and probably we have to slow down the cool stuff .. and focus on the must haves Jan 06 11:29:32 <lsmith> and getting our current features perfect Jan 06 11:29:36 <fabpot> my main concern is probably the Security/ACL component Jan 06 11:29:38 <weaverryan> good point lsmith Jan 06 11:29:39 <fabpot> it's a complex one Jan 06 11:29:45 <lsmith> fabpot: yeah .. i agree Jan 06 11:29:46 <fabpot> lsmith: thanks Jan 06 11:29:48 <Seldaek> yeah that is what I would like now, to figure out what we should focus on in the next week for example Jan 06 11:30:06 * cescalante is now known as ce_afk Jan 06 11:30:10 <jmikola|w> fabpot: the security consultant you're considering for Twig, do you plan on doing something similar for sf2 code (or certain components)? Jan 06 11:30:18 <fabpot> ok, I will work on a detailed roadmap with focus for each week till March Jan 06 11:30:25 <Seldaek> awesome Jan 06 11:30:30 <Seldaek> don't forget the view class ;) Jan 06 11:30:36 <beberlei> sektioneins review probably depends on the money they want to take, or if they even do it for free :) Jan 06 11:30:50 <beberlei> i know phpbb payed them Jan 06 11:31:09 <fabpot> I will send them an email to see how we can work on that Jan 06 11:31:38 <lsmith> i guess we would be ok with them using a security review of sf2 as a PR thing? Jan 06 11:31:47 <beberlei> i dont think they need PR Jan 06 11:31:52 <jmikola|w> good PR for them is bad PR for us :D Jan 06 11:31:53 <lsmith> k Jan 06 11:32:15 * ce_afk is now known as cescalante Jan 06 11:32:21 <lsmith> well the tricky bit .. its hard for them to "certify" anything that isnt "stable" Jan 06 11:32:30 <lsmith> so for twig its feasible for them to "certify" Jan 06 11:32:41 <lsmith> for sf2 core .. all they can is review and help is find issues Jan 06 11:32:58 <lsmith> and maybe then certify a 2.0.3 release Jan 06 11:33:01 <fabpot> lsmith: I will contact them for Twig and I will talk with them about Symfony2 (perhaps they can work on Symfony2 just before SFLive in Paris) Jan 06 11:33:25 <fabpot> that way, we will have time during the hacking day to fix any issue they might find Jan 06 11:33:26 <lsmith> fabpot: we can always look into doing a donation box to get money Jan 06 11:33:38 <lsmith> it doesnt have to be paid by sensio Jan 06 11:33:39 <fabpot> lsmith: yes, I will see how much it costs first Jan 06 11:34:14 <lsmith> ok .. so i guess .. fabpot will work out the details for the roadmap until next week Jan 06 11:34:25 <lsmith> we can discuss the details then on the list and finalize it during next weeks meeting Jan 06 11:34:27 <lsmith> ok? Jan 06 11:34:32 <fabpot> lsmith: yes, I will try to do that this week-end Jan 06 11:34:45 <lsmith> awesome Jan 06 11:34:50 * jackbravo (~email@example.com) has joined #symfony-dev Jan 06 11:34:52 <beberlei> points left? Jan 06 11:34:55 <lsmith> any comments on this topic? Jan 06 11:35:26 <lsmith> i guess in the mean time .. everybody is invited to work on adding tests Jan 06 11:35:34 <lsmith> ideally coordinate via the mailinglist Jan 06 11:35:44 <lsmith> so that we dont end up with duplicate work Jan 06 11:36:17 <lsmith> ok next topic Establishing bundle dependencies: http://bit.ly/hnj58c Jan 06 11:36:29 <lsmith> beberlei you have looked into this a bit? Jan 06 11:36:49 * cescalante is now known as ce_afk Jan 06 11:37:10 <Seldaek> one question I guess is whether fabpot has plans for symfony & bundle packaging already or not Jan 06 11:37:16 <beberlei> yes that is important Jan 06 11:37:29 <fabpot> I will start working on something in the coming days literally Jan 06 11:37:34 <fabpot> but I have nothing yet Jan 06 11:37:35 <beberlei> if packaging is based on pirum + pyrus than dependencies are nativly defined in package.xml Jan 06 11:37:57 <beberlei> i am just not sure how stable pyrus us, i made a ismple prototype that had some flaws in the pyrus core Jan 06 11:37:59 <lsmith> yeah .. what ever we do ... it should be defined in some manifest file Jan 06 11:38:07 <Seldaek> it'd be great if that can be integrated ino app/console, i.e. not rely on pear Jan 06 11:38:20 <beberlei> Seldaek: you can bundle Pyrus into your app/console Jan 06 11:38:25 <beberlei> i prototyped code for this Jan 06 11:38:26 <fabpot> basically, the plan is to have a file where you define your dependencies, and then we resolve all the transient dependencies and let something else actually install the softwares Jan 06 11:38:38 <fabpot> can be a Git repo, a PEAR package, ... Jan 06 11:38:49 <Seldaek> yeah obviously dependencies should be flexible Jan 06 11:39:14 <fabpot> someone at Sensio already worked on the dependencies resolver last week, so the most difficult part is already in the work Jan 06 11:39:33 <fabpot> cannot tell much than that for now Jan 06 11:39:37 <Seldaek> what could be cool is to have one central repo on the symfony site that maps bundle name to paths to pear/git/.. Jan 06 11:39:50 <Seldaek> although that just works for opensource bundles Jan 06 11:39:58 <beberlei> a combination of symfony2bundles + pearhub would be perfect Jan 06 11:39:58 <Seldaek> which is a bit lame Jan 06 11:39:59 <fabpot> ... execpt perhaps that the last time I checked Pyrus, it was not really easy to use their API as many things are hardcoded in their console tool Jan 06 11:40:02 * juokaz has quit (Read error: Connection reset by peer) Jan 06 11:40:19 <beberlei> fabpot: yah i found that too, plus it uses way to much global statics Jan 06 11:40:27 * juokaz (~Juozas@188-223-12-184.zone14.bethere.co.uk) has joined #symfony-dev Jan 06 11:40:38 <lsmith> i am totally out of the loop with their development .. but maybe they appreciate the real world use case and work with us Jan 06 11:41:00 <beberlei> hm dont know Jan 06 11:41:01 <Seldaek> I've not hear one thing of pear in years .. Jan 06 11:41:04 <Seldaek> heard Jan 06 11:41:28 <beberlei> yah maybe we need a pirum for the pear client, anyone up for the task? :p Jan 06 11:41:32 <lsmith> yeah .. who works on this .. just helgi? greg too? Jan 06 11:41:45 <lsmith> maybe we can get one of them to come to SF Jan 06 11:41:55 <beberlei> hm i think neither of them have time Jan 06 11:42:08 <beberlei> no changes for over 6 month Jan 06 11:42:16 <weaverryan> to be clear, are we making a PHP component or something married into Symfony? Jan 06 11:42:17 <lsmith> ok .. i will try to get in contact with the pyrus team Jan 06 11:42:25 <lsmith> to see where things are, who is involved etc Jan 06 11:42:28 <beberlei> as i understand fabien something on top Jan 06 11:42:31 <fabpot> weaverryan: I want something decoupled from Symfony Jan 06 11:42:41 <weaverryan> me too - we make more friends that way Jan 06 11:42:41 <beberlei> i have to run, cya guys Jan 06 11:42:44 <lsmith> i will report my findings to the list asap Jan 06 11:42:48 * beberlei has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) Jan 06 11:42:49 <Seldaek> if we have time left can we spend 5mins discussing the naming thing? http://groups.google.com/group/symfony-devs/browse_thread/thread/96c51eebf8eb0042 Jan 06 11:43:07 <fabpot> hehe, 5 minutes for a hot topic ;) Jan 06 11:43:24 <Seldaek> well, I'm mostly interested to know if anybody minds if I rename Tests to Test Jan 06 11:43:31 <Seldaek> mostly its in the docs I think Jan 06 11:43:36 <lsmith> ok .. do we have anything more on the current topic? Jan 06 11:43:45 <fabpot> I think renaming Tests to Test is a no-brainer Jan 06 11:43:56 <lsmith> then lets do Seldaek's topic .. Jan 06 11:43:56 <weaverryan> yes - are we just planning to do some research and come back on the list per the deps/installer stuff? Jan 06 11:43:58 <Seldaek> the foo_bar vs fooBar issue, I don't think we can reach a solution tbh Jan 06 11:44:07 <lsmith> weaverryan: yes Jan 06 11:44:16 * mapi (~mapi2EE@dslb-092-072-222-038.pools.arcor-ip.net) has joined #symfony-dev Jan 06 11:44:18 <weaverryan> Seldaek I'm with Fabien on that - I don't want to do fooBar Jan 06 11:44:24 <Seldaek> me neither Jan 06 11:44:27 <rande> I like the foo_bar Jan 06 11:44:35 <weaverryan> I never had a problem with well-defined rules of when to use each form Jan 06 11:44:52 <weaverryan> hence the well-defined - we should make sure the coding-standards are fully filled out Jan 06 11:44:55 <Seldaek> I just noticed that there was a little glitch where some things are reaching into both worlds (config & php) Jan 06 11:45:11 <weaverryan> hmm Jan 06 11:45:16 <Seldaek> yes that is also something, I'd like to be able to point new devs at one page that summarizes all that stuff Jan 06 11:45:27 <lsmith> it hasnt really bothered me .. i have more of an issue with the - vs. _ in xml/yaml Jan 06 11:45:49 <Seldaek> yeah that is a bit worse imo Jan 06 11:45:50 <rande> well '_' can be used everywhere Jan 06 11:45:51 <weaverryan> lsmith: me too - but I also realize there's a standard there that we're trying to adhere to that I don't totally understand Jan 06 11:46:04 <Seldaek> rande: - as well can be used everywhere afaik Jan 06 11:46:09 <Stof> yeah, this requires all DIC devs to load the two in from the config Jan 06 11:46:17 <rande> not for class properties Jan 06 11:46:21 <weaverryan> the - and _ is hard to document Jan 06 11:46:36 <fabpot> Stof: yeah, that's a big problem Jan 06 11:46:41 <Seldaek> rande: ah, sure I meant yaml or xml doesn't matter Jan 06 11:46:48 <Stof> well, maybe the XML loader should make the replacement Jan 06 11:47:03 <weaverryan> Stof: that sounds dangerous Jan 06 11:47:04 <Seldaek> Stof: maybe, but that's wtf-leading magic Jan 06 11:47:11 <Stof> so the Extensions only get _ Jan 06 11:48:08 <lsmith> hmm .. Jan 06 11:48:19 <Stof> or a method in the base class Extension so the devs can use it easily without recoding it each time Jan 06 11:48:55 <lsmith> sounds less dangerous :) Jan 06 11:49:15 <weaverryan> I'd just rather either leave it how it is now or remove the inconsistency Jan 06 11:49:27 <weaverryan> though I don't like it, the Extensions themselves are fairly easy to understand in this regard Jan 06 11:49:36 <weaverryan> foreach (array('my-var', 'my_var')) Jan 06 11:49:40 <Seldaek> yeah, it's just ugly Jan 06 11:49:40 <Stof> and then it is explicitly called in the *load() method if the devs wants it Jan 06 11:49:41 <lsmith> yeah .. i favor just going with either one .. even if it doesnt look good in one of the formats Jan 06 11:49:42 <weaverryan> it's a little weird - but I get that Jan 06 11:50:00 <lsmith> because imho we should pick clear favorites for a format Jan 06 11:50:21 <lsmith> and optimize sf2 for that Jan 06 11:50:21 <lsmith> and leave the option of the other formats for the freaks :) Jan 06 11:50:41 <Seldaek> well but that was exactly my point above Jan 06 11:50:47 <Seldaek> what is the problem with using - in yaml? Jan 06 11:50:51 <Stof> weaverryan: it is easy to do so but it has to be in all bundles Jan 06 11:51:01 <rande> '_' is more readable Jan 06 11:51:09 <fabpot> Seldaek: If we need to choose one format, let's keep _ instead Jan 06 11:51:10 <rande> from my point of view ;) Jan 06 11:51:25 <fabpot> as _ is already used everywhere else Jan 06 11:51:32 <rande> my_super_key vs my-super-key Jan 06 11:51:46 <lsmith> maybe someone just needs to write out the issue in detail and put up a doodle where people can express their preference Jan 06 11:51:50 <lsmith> and fabien takes the final decision Jan 06 11:51:59 <Seldaek> nah come on Jan 06 11:52:03 <Seldaek> democracy sucks :p Jan 06 11:52:09 <Seldaek> voicing opinions, sure, but votes are useless Jan 06 11:52:11 <fabpot> Seldaek: +1 Jan 06 11:52:20 <lsmith> which is why i just gave fabien final veto power :) Jan 06 11:52:21 <weaverryan> haha Jan 06 11:52:23 <fabpot> we can discuss it on the mailing-list Jan 06 11:52:24 <rande> _ +1 Jan 06 11:52:24 <Seldaek> look at php internals votes, it's just absurd Jan 06 11:52:29 <weaverryan> well, e can all vote and then Fabien can decide Jan 06 11:52:38 <weaverryan> then everyone can think that it was done how they wanted Jan 06 11:52:40 <fabpot> weaverryan: which does not make sense then Jan 06 11:52:52 <weaverryan> haha, I know Jan 06 11:52:55 <lsmith> well it gives everybody a chance to express their preference Jan 06 11:53:07 <fabpot> that's why a discussion on the ML is better than a vote Jan 06 11:53:14 <Seldaek> yeah but then they're pissed if it goes against their preference Jan 06 11:53:15 <rande> just use '_' everywhere ;) in class properties, in yaml, in xml … Jan 06 11:53:28 <Seldaek> if they didn't express it , they're not disappointed :) Jan 06 11:53:29 <lsmith> to me discussing such a topic is hopeless Jan 06 11:53:42 <lsmith> its like talking about what color is more beautiful Jan 06 11:53:45 <Seldaek> well yes, so let's go for _, it sorta makes sense Jan 06 11:53:52 <Stof> and it has still been discussed on the ml Jan 06 11:54:07 <lsmith> ok .. whats the conclusion? Jan 06 11:54:18 <Seldaek> - doesn't have any arguments aside from "looks good in xml", _ is at least common in option names already Jan 06 11:54:30 <rande> lsmith: use _ everywhere (it's a nice conclusion( Jan 06 11:54:33 <lsmith> so we agree on _ .. Jan 06 11:54:37 <Seldaek> yes Jan 06 11:54:42 <lsmith> last topic then Jan 06 11:54:49 <fabpot> ... except if we decide to use camelCase everywhere ;) Jan 06 11:54:55 <Seldaek> yeah that'd fix everything Jan 06 11:55:21 * You are now known as jMikola|w Jan 06 11:55:21 <lsmith> so no agreement yet? Jan 06 11:55:22 <rande> fabpot: well, camel_case_sucks Jan 06 11:55:24 <Stof> but it seems weird in xml AND in yaml :) Jan 06 11:55:32 * You are now known as j_mikola|w Jan 06 11:55:46 <rande> j_mikola|w: lol Jan 06 11:55:50 * You are now known as jmikola|w Jan 06 11:55:52 <Seldaek> j_mikola|w: are you suggesting we should use | as separator? Jan 06 11:55:55 <jmikola|w> lsmith: what's the last topic? Jan 06 11:56:01 <lsmith> RFC for DIC template syntax: http://bit.ly/fAmNKo Jan 06 11:56:09 <jmikola|w> Seldaek: no, don't worry :) Jan 06 11:56:10 <lsmith> probably not doable in 5mins Jan 06 11:56:21 <fabpot> lsmith: Spring has support for service templates Jan 06 11:56:25 <lsmith> and we worked through a lot of topics today already Jan 06 11:56:34 <jmikola|w> is security component the big user of this thing? Jan 06 11:56:41 * dwhittle (~firstname.lastname@example.org) has joined #symfony-dev Jan 06 11:56:46 <fabpot> jmikola|w: yes, and Doctrine Jan 06 11:56:58 <jmikola|w> perhaps we lead next week with a thorough discussion of this? 4 min does seem a bit short Jan 06 11:57:01 <Seldaek> controllers tend to repeat a lot of argument lists too, if you define them as services Jan 06 11:57:01 <lsmith> fabpot: what i am looking for is a syntax to reuse (copy+modify) templates inside xml/yaml Jan 06 11:57:04 <fabpot> but I'm not sure we need something special here Jan 06 11:57:22 <fabpot> ok, let's talk about that next week Jan 06 11:57:25 <lsmith> yeah Jan 06 11:57:35 <jmikola|w> it sounds like the mailing list ended on a question anyway, from beberlei Jan 06 11:57:39 <lsmith> i will write up a summary as per usual Jan 06 11:57:43 <jmikola|w> so this can continue during the week Jan 06 11:57:48 <jmikola|w> lsmith: i'll grab the logs in a minute Jan 06 11:57:51 <Seldaek> alright, have fun then Jan 06 11:57:57 <lsmith> thx all .. good stuff Jan 06 11:58:08 <lsmith> i am excited about our final stretch until stable!