You must first sign up to be able to contribute.


including assets

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 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.

IRC logs

Jan 06 11:00:22 <lsmith>	ok .. meeting time ..
Jan 06 11:00:32 <lsmith>	including assets:
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 ( 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:
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> and
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:
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 ( 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:
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>
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 (~jackbravo@ 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:
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 ( 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?
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 ( 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:
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 ( 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!