Log of #symfony-dev meeting 20101111 (all times GMT-5)

symfony_dev.log

Nov 11 11:00:10 <lsmith>	ok lets start ..
Nov 11 11:00:33 <lsmith>	so i am quite thrilled to see so many people here .. and also that fabpot managed to come after all
Nov 11 11:01:13 <lsmith>	i think we do not need to ask for permission to speak, but try to make sure that stuff that is said is well thought out .. and rather take it slower than faster
Nov 11 11:01:34 <lsmith>	also i think when we start on a topic, it would be good for the person who proposed the topic to briefly introduce the topic
Nov 11 11:01:52 *	nicobn ([email protected]) has joined #symfony-dev
Nov 11 11:02:07 <lsmith>	also when saying something for the first time with a nickname that isnt obvious as to what the name that is used on the mailinglist, one should mention the name the first time speaking
Nov 11 11:02:24 <lsmith>	ok .. so the first topic today is this IRC meeting process
Nov 11 11:02:34 <lsmith>	i proposed that one .. my name is Lukas Smith btw :)
Nov 11 11:02:53 <lsmith>	i came up with this IRC meeting idea, since the in person meetings kinda fell through for now
Nov 11 11:03:13 <lsmith>	i proposed the topic to ensure that others have the chance to also provide input on the process itself
Nov 11 11:03:26 <lsmith>	so if anyone has specific ideas please speak up now
Nov 11 11:03:30 *	clement__ ([email protected]) has joined #symfony-dev
Nov 11 11:03:42 <lsmith>	the "process" itself is explain in the doodle: http://doodle.com/4cnzme7xys3ay53w
Nov 11 11:03:50 <lsmith>	i will continue to create new doodles
Nov 11 11:03:51 *	clement__ ([email protected]) has left #symfony-dev
Nov 11 11:03:53 <lsmith>	for each week
Nov 11 11:03:58 *	IamPersistent has quit (Ping timeout: 265 seconds)
Nov 11 11:03:59 *	Dator ([email protected]) has joined #symfony-dev
Nov 11 11:04:02 <lsmith>	with the topics as they are proposed on the list
Nov 11 11:04:04 *	IamPersistent ([email protected]) has joined #symfony-dev
Nov 11 11:04:31 <lsmith>	if there is nothing to add at this point we can just continue on to the next topic ..
Nov 11 11:04:34 <nicobn>	lsmith: maybe we should create a separate channel ?
Nov 11 11:04:51 <Seldaek>	this channel was more or less made for this
Nov 11 11:04:53 <nicobn>	less come-and-go, only unlocked when there is a meeting
Nov 11 11:05:03 <fabpot>	the process looks good to me. Easy enough. Once a week seems reasonable for the start but we will probably have less as we approach the first RC release
Nov 11 11:05:05 <pgodel_work>	can we include the above "rules" in some place linked from this channel ? it will help the newcomers and keep the discussion organized
Nov 11 11:05:54 <lsmith>	pgodel_work: good point, there is limitation on the amount of text allowed in the doodle, but i will create a wiki page with the logs
Nov 11 11:06:04 <fabpot>	we can add a document in the Symfony2 docs (contribute section) about these meetings with the rules
Nov 11 11:06:08 <lsmith>	so i will add some more information there and always link to that page in the doodle
Nov 11 11:06:19 <pgodel_work>	sounds great
Nov 11 11:06:21 <lsmith>	fabpot: ah even better!
Nov 11 11:07:02 <jmikola|w>	lsmith: i meant to mention that the checkbox voting wasn't so clear
Nov 11 11:07:07 <lsmith>	nicobn: this channel might now turn into a symfony2 channel .. so at some point me might want a dedicated channel
Nov 11 11:07:34 <lsmith>	but as Seldaek pointed out .. this channel was deserted before i announced the weekly meetings
Nov 11 11:07:38 *	OlegZinchenko has quit (Ping timeout: 245 seconds)
Nov 11 11:07:54 <lsmith>	jmikola|w: yeah .. i will make that clearer .. so the idea is that people can essentially wait with voting until the proposal phase has closed
Nov 11 11:07:55 <johanness>	btw, voting shouldn't start before all topics have been proposed
Nov 11 11:08:16 <lsmith>	right .. however you can always correct your vote later on
Nov 11 11:08:22 <Seldaek>	well, people also don't realize that you can edit (any) entries on doodle..
Nov 11 11:08:28 <Seldaek>	but their interface is shit for that
Nov 11 11:08:34 <lsmith>	i will make sure to add this in the instructions
Nov 11 11:08:47 <Seldaek>	anyways, no need to create the doodle before the end of the proposal phase imo
Nov 11 11:08:51 <Seldaek>	then it's clear.
Nov 11 11:08:51 *	Dator has quit (Quit: Dator)
Nov 11 11:09:02 *	nanderoo ([email protected]) has joined #symfony-dev
Nov 11 11:09:08 <lsmith>	Seldaek: well i want to make sure that people see whats going to be discussed as early as possible
Nov 11 11:09:16 <jmikola|w>	Seldaek: proposal phase is 24 hours before the meeting - is that enough time to cast votes?
Nov 11 11:09:17 *	joshuamorse ([email protected]) has joined #symfony-dev
Nov 11 11:09:23 <lsmith>	and that proposers know that i took care of adding their proposal
Nov 11 11:09:55 <lsmith>	jmikola|w: right another good point .. then again its not the end of the world if someone cant vote .. there is always next week ..
Nov 11 11:09:57 *	thoas ([email protected]) has joined #symfony-dev
Nov 11 11:10:04 *	stanchollet (18ca9560@gateway/web/freenode/ip.24.202.149.96) has joined #symfony-dev
Nov 11 11:10:06 <Seldaek>	lsmith: if proposals are on the ml I don't see the problem
Nov 11 11:10:30 <Seldaek>	I doubt people really don't want to have a point discussed though, it's just for priorization so it doesn't matter too much
Nov 11 11:10:40 *	lsmith nods
Nov 11 11:10:43 <pgodel_work>	agree
Nov 11 11:10:43 *	mpiecko (michael.pi@HSI-KBW-109-192-054-025.hsi6.kabel-badenwuerttemberg.de) has joined #symfony-dev
Nov 11 11:11:14 <lsmith>	ok .. so i should create the doodle when the proposal phase closes (aka 24h before the meeting) .. quick +1/-1 please
Nov 11 11:11:22 <fabpot>	+1
Nov 11 11:11:23 <johanness>	+1
Nov 11 11:11:23 <everzet>	+1
Nov 11 11:11:25 <avalanche123>	+1
Nov 11 11:11:25 <pgodel_work>	+1
Nov 11 11:11:32 <abem_>	+1
Nov 11 11:11:40 <Seldaek>	+1 | what this shows though, is that it takes us 10 minutes to agree on not-so-much of a problem, afraid of the next topic's 15minutes :)
Nov 11 11:11:51 <lsmith>	yeah :)
Nov 11 11:12:00 <lsmith>	ok .. moving on then
Nov 11 11:12:09 <lsmith>	just one more thing that i already said on the list
Nov 11 11:12:23 <lsmith>	the goal of these meetings must not be to finalize stuff all the time
Nov 11 11:12:32 <lsmith>	but to make sure we get a common understanding of issues
Nov 11 11:12:40 *	mridgway ([email protected]) has joined #symfony-dev
Nov 11 11:12:44 <lsmith>	we can still talk about stuff on the list, github etc
Nov 11 11:12:44 *	OlegZinchenko ([email protected]) has joined #symfony-dev
Nov 11 11:12:46 *	mastho ([email protected]) has joined #symfony-dev
Nov 11 11:12:50 *	sitron ([email protected]) has joined #symfony-dev
Nov 11 11:12:53 *	lee1 ([email protected]) has joined #symfony-dev
Nov 11 11:13:02 <lsmith>	ok .. next topic is handling different output formats
Nov 11 11:13:08 <lsmith>	again a topic i proposed :)
Nov 11 11:13:36 *	henrikbjorn ([email protected]) has joined #symfony-dev
Nov 11 11:13:46 <lsmith>	i did a blog post about the general issue http://pooteeweet.org/blog/1850
Nov 11 11:14:00 *	noginn ([email protected]) has joined #symfony-dev
Nov 11 11:14:05 <lsmith>	and on the list there has been a proposed solution by adding "context" to the DIC
Nov 11 11:14:22 <lsmith>	others have stated that they think this should rather be handled with custom code inside the controllers
Nov 11 11:14:28 <lsmith>	that we define as a best practice
Nov 11 11:14:33 *	Bouke ([email protected]) has joined #symfony-dev
Nov 11 11:14:46 *	ornicar ([email protected]) has joined #symfony-dev
Nov 11 11:14:55 <fabpot>	I vote against adding contexts in the DIC
Nov 11 11:15:11 <fabpot>	that is yet another layer of complexity and I'm sure we don't need that at all
Nov 11 11:15:14 <avalanche123>	I vote for best practice
Nov 11 11:15:30 <mahono>	can u sumarize the problem in one or two sentences?
Nov 11 11:15:43 <henrikbjorn>	+1 for Best practice
Nov 11 11:15:54 *	juvabien (5138322d@gateway/web/freenode/ip.81.56.50.45) has joined #symfony-dev
Nov 11 11:16:01 <noginn>	+1 best practice
Nov 11 11:16:20 <lsmith>	mahono: the problem is that currently in order for a Bundle to be useful for outputting different formats (html, json, pdf, etc) you need to add custom code to the controller, to be sufficiently extensible
Nov 11 11:16:49 <lsmith>	since usually you need to override the Response and Templating services dynamically to match the required format
Nov 11 11:16:58 <fabpot>	lsmith: or define a View where you manage the different outputs
Nov 11 11:17:09 *	develop7 ([email protected]) has joined #symfony-dev
Nov 11 11:17:09 <Seldaek>	I (btw Jordi Boggiano in case it's not clear) would be against contexts, but I don't think a best practice is enough, I'd like to have the view-class best practice integrated at the framework level so the best practice is easier to implement and follow. And I'll try to work on that next week now that pressure is going down at work.
Nov 11 11:17:10 <lsmith>	right .. which means you need a "super view"
Nov 11 11:17:23 *	OlegZinchenko has quit (Ping timeout: 276 seconds)
Nov 11 11:17:33 <abem_>	+1 for Seldaek
Nov 11 11:17:53 <avalanche123>	isn't Response objects sort of a view?
Nov 11 11:17:56 *	Garfield-fr has quit (Quit:  ⏏)
Nov 11 11:18:03 <fabpot>	avalanche123: not really
Nov 11 11:18:04 *	mofoe333 ([email protected]) has joined #symfony-dev
Nov 11 11:18:07 <fabpot>	it's only part of the View
Nov 11 11:18:07 *	Crafty_Shadow ([email protected]) has joined #symfony-dev
Nov 11 11:18:16 *	darksmith ([email protected]) has joined #symfony-dev
Nov 11 11:18:24 <fabpot>	Templating is another (optional) part of the View
Nov 11 11:18:26 <Seldaek>	lsmith: contexts might still be interesting for super advanced cases, but that could be implemented as an "superpowered" DIC class don't you think?
Nov 11 11:18:48 <Seldaek>	I mean, implement it somewhere so that it's available, but not in the default Sf2 code
Nov 11 11:18:50 <fabpot>	Seldaek: Let's work/think about how we can propose an optional View system
Nov 11 11:19:04 *	OlegZinchenko ([email protected]) has joined #symfony-dev
Nov 11 11:19:07 *	OlegZinchenko has quit (Client Quit)
Nov 11 11:19:22 <pgodel_work>	Seldaek: that seems to be a good alternative
Nov 11 11:19:32 <lsmith>	Seldaek: yes .. context can essentially be a wrapper around the DIC, since its mostly about making the lookup name dynamic (and also helping in defining fallback rules before the DIC is cached to reduce overhead at runtime)
Nov 11 11:19:39 <jmikola|w>	The online docs are certainly light about serious View development - they rather skip from controllers to template rendering, so I'd be in favor of getting some best practices and code examples for that online
Nov 11 11:20:07 <fabpot>	jmikola|w: light is an understatement ;)
Nov 11 11:20:07 <avalanche123>	jmikola|w + 1
Nov 11 11:20:17 <jmikola|w>	i'm being generous :)
Nov 11 11:20:20 *	jwage ([email protected]) has joined #symfony-dev
Nov 11 11:20:55 *	OlegZinchenko (c16cf96c@gateway/web/freenode/ip.193.108.249.108) has joined #symfony-dev
Nov 11 11:21:00 <Seldaek>	fabpot: well, if you remember my mail, what I wanted to have is that a default view class is provided by Sf2, if a controller return snothing, the framework would instanciate the default view and use that. Imo controllers should have a getHtmlTemplate() and getData() methods in their interface though, so that the default view can extract stuff from it
Nov 11 11:21:35 <Seldaek>	if you want though you can instanciate and return a custom view, or better return a string which would be the service name of the view (so it's easier to override)
Nov 11 11:22:18 <fabpot>	Seldaek: everything is possible right now
Nov 11 11:22:19 *	nicolasbinet ([email protected]) has joined #symfony-dev
Nov 11 11:22:20 <Seldaek>	the main conceptual issue I have with this is redirects
Nov 11 11:22:27 <fabpot>	return ViewService('foo.bar');
Nov 11 11:22:41 <fabpot>	I mean return new ViewService('foo.bar');
Nov 11 11:22:53 <fabpot>	redirects are part of the View
Nov 11 11:22:59 <Seldaek>	yes of course it's possible right now, but you don't have a default view class atm that handles json (json_encode the data array), xml (converts array to xml), html (use getHtmlTemplate and render that)
Nov 11 11:23:20 <fabpot>	Seldaek: so, let's work on that ;)
Nov 11 11:23:30 <Seldaek>	yes.. that'd make me happy :p
Nov 11 11:23:45 <jmikola|w>	fabpot: is the absence of redirect exceptions intentional?  that seems to be a big missing feature from sf1
Nov 11 11:23:47 <fabpot>	Seldaek: we can definitely have a look at how Spring does that
Nov 11 11:23:51 <Seldaek>	all I want is to go away from the "controller returns a response" model to a more view centric approach
Nov 11 11:24:00 <lsmith>	also pretty much all Bundle's right now are not extensible in the above way
Nov 11 11:24:07 <fabpot>	Seldaek: nope, that won't happen
Nov 11 11:24:18 <lsmith>	since they inject the container, use hardcoded service names
Nov 11 11:24:23 <Seldaek>	fabpot: why ?
Nov 11 11:24:23 <fabpot>	"Controllers should return a Response, if not, a View must be implemented"
Nov 11 11:24:28 <abem_>	fabpot, but why?
Nov 11 11:24:44 <fabpot>	because I want Symfony2 to be as easy as possible to understand for newcomers
Nov 11 11:24:49 <Seldaek>	fabpot: that's the problem, you force people to implement a view, so they go for the easy way, and then their code is not reusable
Nov 11 11:24:59 <Seldaek>	if you have an implicit view by default, code is reusable, and still easy to grasp
Nov 11 11:25:00 *	lsmith nods to Seldaek
Nov 11 11:25:07 <fabpot>	You must understand that not all code need to be reusable
Nov 11 11:25:16 <fabpot>	far from it
Nov 11 11:25:18 <Seldaek>	not but it could be at almost no effort imo
Nov 11 11:25:33 <avalanche123>	and if it needs to be reusable - you can submit patches
Nov 11 11:25:38 <avalanche123>	and pull requests
Nov 11 11:25:40 <abem_>	most of the time that view logic would be "empty" or very generic - so no additional complexity would be introduced.
Nov 11 11:25:40 <fabpot>	you introduce another class for every resource, that's a lot of effort
Nov 11 11:25:50 <Seldaek>	I can work on that with whoever is interested and present it for next week..
Nov 11 11:25:51 *	hidenorigoto ([email protected]) has joined #symfony-dev
Nov 11 11:26:03 <lsmith>	ok .. we are getting close to the timebox limit
Nov 11 11:26:09 <abem_>	fabpot: no its not, it doesn't have to be agavi clone
Nov 11 11:26:09 *	Assassik ([email protected]) has joined #symfony-dev
Nov 11 11:26:16 <johanness>	how much is performance impacted by that?
Nov 11 11:26:18 <lsmith>	the general feeling is that people prefer going the route of a best practice
Nov 11 11:26:32 <lsmith>	rather than making this need part of the core
Nov 11 11:26:52 <avalanche123>	+1 best practice and good view documentation
Nov 11 11:26:58 <everzet>	+1
Nov 11 11:27:02 <Seldaek>	fabpot: I definitely don't think the agavi way is sane for newcomers, don't get me wrong, but I think there is a middle ground in there that we can find and agree upon
Nov 11 11:27:10 <lsmith>	yeah .. and we need people to help on expanding the documentation in regards to views
Nov 11 11:27:15 <abem_>	lsmith: at this moment "the route of a best practice" is just bunch of if's in actions
Nov 11 11:27:17 *	OlegZinchenko has quit (Quit: Page closed)
Nov 11 11:27:20 <lsmith>	feel free to raise your hand on the list if you want to help there :)
Nov 11 11:27:21 <fabpot>	let's wait for a proof-of-concept to be able to discuss that matter more
Nov 11 11:27:30 <lsmith>	ok .. next topic .. johanness
Nov 11 11:27:33 <lsmith>	security component
Nov 11 11:27:36 *	jeromet ([email protected]) has joined #symfony-dev
Nov 11 11:27:53 <johanness>	yeah thx lukas, my name is Johannes Schmitt, same on the mailing list, or just short Johannes
Nov 11 11:27:56 *	mig81 (547ef403@gateway/web/freenode/ip.84.126.244.3) has joined #symfony-dev
Nov 11 11:27:58 <pgodel_work>	+1 for let's wait for a proof-of-concept to be able to discuss that matter more
Nov 11 11:28:08 <abem_>	+1
Nov 11 11:28:12 <Seldaek>	fabpot: alright, will try to get that done next week, if anyone is interested please query me or something (sorry for hijacking johanness, please proceed)
Nov 11 11:28:37 <fabpot>	Seldaek: but please, keep in mind what we said and have a look at Spring (let's try to not reinvent the wheel ;))
Nov 11 11:28:51 <johanness>	i've also made a post about that (http://groups.google.com/group/symfony-devs/msg/26113efc1207b30a), best if you quickly read the third paragraph if you haven't used the component much
Nov 11 11:29:07 <fabpot>	I have not had time to read your post yet
Nov 11 11:30:06 <johanness>	mainly it centers around how we can change the SecurityExtension to improve configuration (more consistency, and better extensibility)
Nov 11 11:30:47 <johanness>	i think we probably should first discuss paragraph 4 and 5
Nov 11 11:30:50 <fabpot>	johanness: the rule is the following: if a listener can be shared, let's do taht. If not (because the listener has some configuration for instance), it should be a different one for each firewall
Nov 11 11:31:34 <fabpot>	keep in mind that this is a proof-of-concept and it can be improved in the next coming weeks
Nov 11 11:31:40 <jmikola|w>	i think the issue of shared listeners and unintentionally shared DI parameters is one problem expressed in johanness post
Nov 11 11:31:41 <johanness>	there's a problem with sharing since each listener shares the same parameter in the DI container?
Nov 11 11:31:46 <fabpot>	configuration is probably one area where we can improve things a lot
Nov 11 11:32:05 <jmikola|w>	so that seems like a good opportunity to contribute a patch or two
Nov 11 11:32:06 *	jeromet_ ([email protected]) has joined #symfony-dev
Nov 11 11:32:22 <abem_>	fabpot: is XML schema for security configuration planned?
Nov 11 11:32:27 <fabpot>	johanness: as I said, if there is a problem with shared listeners, we can definitely create one per configuration
Nov 11 11:32:33 <johanness>	well yeah, but i think we need to agree on a best practice here, where should the configuration come from if not from parameters?
Nov 11 11:32:42 <fabpot>	abem_: hehe, I'm just waiting for a patch ;)
Nov 11 11:32:51 <johanness>	we would need to set them directly in the arguments?
Nov 11 11:32:53 <fabpot>	johanness: what do you mean?
Nov 11 11:33:01 *	notjosh ([email protected]) has joined #symfony-dev
Nov 11 11:33:29 *	jeromet has quit (Ping timeout: 245 seconds)
Nov 11 11:33:30 <johanness>	fabpot: as i see it, we cannot use $container->setParameter('some options'), but have to use $container->getDefinition('mydynamicservice')->setArguments(), dont we?
Nov 11 11:33:32 *	jeromet_ is now known as jeromet
Nov 11 11:33:35 <jmikola|w>	johanness: i think the current DI container would require we give them as arguments or perhaps a setOptions() array on the dynamic (non-shared) listeners
Nov 11 11:33:43 <avalanche123>	either set them directly or suffix parameter name - so that they are unique per listener
Nov 11 11:34:09 <fabpot>	avalanche123: exactly. and this is already done that way in quite a few places
Nov 11 11:34:37 <fabpot>	johanness: you can set a parameter directly if you want
Nov 11 11:34:46 *	Scorfly ([email protected]) has joined #symfony-dev
Nov 11 11:34:53 <jmikola|w>	avalanche123: i gather from johanness' post that it'd be a problem for params used for even a single listener type - for cases where it's not a shared service
Nov 11 11:34:55 *	Yrwein (93207fd5@gateway/web/freenode/ip.147.32.127.213) has joined #symfony-dev
Nov 11 11:34:58 <johanness>	http://pastie.org/1269433
Nov 11 11:35:57 <jmikola|w>	based on that, i don't think non-shared services should be using DI params for configurable options
Nov 11 11:36:04 <fabpot>	johanness: I understand this problem and it can be fixed quite easily. If someone can work on a patch I will be happy. If not, let's create a ticket and I will work on it (should be quite easy)
Nov 11 11:36:05 <johanness>	but if we use ->setArguments(), we probably would need a common interface for listeners, so that the can actually exchanged
Nov 11 11:36:07 <jmikola|w>	if those options should vary based on each instance
Nov 11 11:36:27 *	mastho ([email protected]) has left #symfony-dev
Nov 11 11:36:52 <johanness>	ok, then this should be solved
Nov 11 11:36:57 *	Skorney has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630])
Nov 11 11:37:06 <fabpot>	jmikola|w: I would have said it the other way around: services with DI params cannot be shared
Nov 11 11:37:28 <avalanche123>	johanness so the solution is to make parameter names more specific - 'security.context.pattern' becomes 'security.context.pattern.admin' for example
Nov 11 11:37:42 <avalanche123>	it could be done in the extenstion pretty easily
Nov 11 11:37:54 <fabpot>	avalanche123: and I'm sure the security configuration already does that a lot
Nov 11 11:37:57 <johanness>	what i fear is that this is not transparent
Nov 11 11:38:14 <avalanche123>	fabpot, yeah, I've seen this tactic in a lot of places
Nov 11 11:38:16 <johanness>	and most people will not know what is going on behind the scenes if we create all that dynamically
Nov 11 11:38:17 <fabpot>	johanness: transparent?
Nov 11 11:38:18 *	FabienPomerol (56439faa@gateway/web/freenode/ip.86.67.159.170) has joined #symfony-dev
Nov 11 11:38:28 <avalanche123>	johanness, most people don't need to
Nov 11 11:38:32 <avalanche123>	only bundle developer do
Nov 11 11:38:32 <lsmith>	johanness: if you wanted to touch on another aspect, you might want to move on to that .. since we only have 5 more minutes for this topic
Nov 11 11:38:35 <avalanche123>	and they will
Nov 11 11:38:37 <johanness>	if we have an interface like ->setOptions() then is clear where the options are coming from
Nov 11 11:38:52 <fabpot>	johanness: and that's the whole point of the extension, right?
Nov 11 11:39:36 *	I (d579cc7b@gateway/web/freenode/ip.213.121.204.123) has joined #symfony-dev
Nov 11 11:39:47 <johanness>	ok lets go to the next part, the priority of listeners (currently they all have the same priority), maybe we should change that so there are actually some gaps in priorities for easier extensibility
Nov 11 11:40:02 *	I is now known as Guest5882
Nov 11 11:40:03 <fabpot>	I think the first easy step is to move listeners with parameters to non-shared services
Nov 11 11:40:07 <johanness>	i think, this also applies to other parts of the code not only the security component
Nov 11 11:40:26 <johanness>	agreed
Nov 11 11:40:35 <johanness>	also better for consistency
Nov 11 11:40:57 <avalanche123>	+1
Nov 11 11:41:14 <everzet>	+1
Nov 11 11:41:14 <fabpot>	johanness: adding a way to add listeners in between of existing ones would be a nice second step
Nov 11 11:41:31 *	jebbench (d579cc7b@gateway/web/freenode/ip.213.121.204.123) has joined #symfony-dev
Nov 11 11:41:35 <fabpot>	I think we need to know who is going to work on things we vote on, right?
Nov 11 11:41:47 <lsmith>	Seldaek: get ready .. we will soon move to your topic :)
Nov 11 11:41:59 <pgodel_work>	fabpot: :)
Nov 11 11:42:21 <lsmith>	fabpot: i will try to write up a summary of stuff we agreed to change, write proof of concepts to the list
Nov 11 11:42:35 <avalanche123>	lsmith, I think it would be very helpful
Nov 11 11:42:37 <lsmith>	so that people can put their name on stuff like that .. or maybe i will create tickets
Nov 11 11:42:44 <lsmith>	and send the list of tickets
Nov 11 11:42:45 <avalanche123>	that way if I have some time, I can pick one and work on it
Nov 11 11:42:50 <fabpot>	lsmith: tickets looks better
Nov 11 11:42:57 <lsmith>	ok will do
Nov 11 11:43:00 <johanness>	fabpot: maybe we should start getting together a list of events and default listeners on it since there are already bugs due to conflicting priorities
Nov 11 11:43:08 <fabpot>	avalanche123: you should first work on the DI stuff...  :P
Nov 11 11:43:15 <avalanche123>	fabpot, yeah:)
Nov 11 11:43:40 <fabpot>	johanness: Spring has names for each listener slots (I think this is what we can have too -- easy to code and understand)
Nov 11 11:43:48 <lsmith>	ok .. last topic for the day .. Seldaek on "default config format"
Nov 11 11:44:00 <Seldaek>	so the issue with configuration files atm imo is fragmentation, that's no good for newcomers, and it's annoying for everyone I'm sure. The recommended default is XML, for (imo) questionable reasons. I'd like to revisit this, and promote yaml instead
Nov 11 11:44:04 <avalanche123>	"yaml" for app level configs
Nov 11 11:44:08 <avalanche123>	xml for DIC
Nov 11 11:44:19 <Seldaek>	avalanche123: this is still fragmented
Nov 11 11:44:22 <fabpot>	avalanche123: hehe, exactly what I was going to say ;)
Nov 11 11:44:30 <henrikbjorn>	+yaml/php
Nov 11 11:44:40 <avalanche123>	I know it is, but there is no one solution fits it all
Nov 11 11:44:46 <jmikola|w>	avalanche123: that conveniently allows us to avoid making XSD's for our bundle configs :)
Nov 11 11:44:46 <avalanche123>	right tool for the job, remember?
Nov 11 11:44:49 <Seldaek>	then fabpot & avalanche123, could you please tell me why?
Nov 11 11:44:49 <fabpot>	I think everybody agree on YAML for app configuration
Nov 11 11:45:06 <avalanche123>	yaml for DIC is just not readable
Nov 11 11:45:10 <Seldaek>	why xml for Bundle DIC?
Nov 11 11:45:12 <jwage>	yaml is tough for the complex data structures but app level configurations are always going to be pretty simple key => value pairs if the DI extension is  built right
Nov 11 11:45:18 <avalanche123>	jwage +1
Nov 11 11:45:27 <jwage>	yaml is perfect for app configuration, but for anything more complex it is tough
Nov 11 11:45:31 <fabpot>	Bundle DIC is about parameters and services
Nov 11 11:45:34 <Seldaek>	well, I don't agree there.. We've shitloads of services defined in yaml here, and it works pretty well
Nov 11 11:45:37 <pgodel_work>	fabpot: do you have some of the slides you showed last week at the meetup? they showed quite well the problem
Nov 11 11:45:46 <jwage>	Seldaek: i didnt say it doesnt work
Nov 11 11:45:56 <jwage>	Seldaek: I said its tougher to write complex structures in yaml
Nov 11 11:46:01 <jwage>	with xml you get ide help
Nov 11 11:46:02 <Seldaek>	well, to me it's more readable than XML
Nov 11 11:46:02 <avalanche123>	and to read them
Nov 11 11:46:07 <jwage>	and the services definition can be very complex
Nov 11 11:46:11 *	JayExercise has quit (Ping timeout: 265 seconds)
Nov 11 11:46:11 <avalanche123>	hmm, I would argue there
Nov 11 11:46:11 <jwage>	its not about readability
Nov 11 11:46:17 <jwage>	anyways
Nov 11 11:46:20 <lsmith>	one of the issues i have with having support for different formats, is that right now there are lots of issues with mixing formats
Nov 11 11:46:38 <jmikola|w>	i've had no troubles writing bundle DIC in XML - it lends itself well to that; and bundle DIC is likely something a casual developer (framework end user) would never have to write; as opposed to app configs
Nov 11 11:46:43 <henrikbjorn>	WHO here have an ide with XML help?
Nov 11 11:46:51 <avalanche123>	me!
Nov 11 11:46:56 <lsmith>	of course there are bugs in other parts too, but i wonder if we will ever get to the point where its smooth extending stuff defined in one format, inside another format
Nov 11 11:46:59 <jwage>	me
Nov 11 11:47:02 <IamPersistent>	 I do
Nov 11 11:47:05 <Seldaek>	well, another issue of having XML for bundles is that say you get a bundle, you want to redefine a service and change a few things, if you're not used to the XML syntax, you have to convert it to yaml to add it to your app config, and that is not especially straightforward
Nov 11 11:47:15 <abem_>	henrikbjorn: I do and I'm quite happy with that.
Nov 11 11:47:15 <mvrhov>	I do, but I still hate writing XML
Nov 11 11:47:30 <avalanche123>	Seldaek, yaml is still supported for DIC, just not default recommended
Nov 11 11:47:39 <avalanche123>	so you could potentially overload XML DIC in yaml
Nov 11 11:47:42 <avalanche123>	correct?
Nov 11 11:47:44 <jwage>	lsmith: ive seen people complain about mixing formats but ive never seen the issues really
Nov 11 11:47:50 <jwage>	and the reports havent really been solid
Nov 11 11:47:59 <jwage>	what is the issue?
Nov 11 11:48:02 <Seldaek>	avalanche123: of course you can. But you have to convert the stuff to edit it, you can't just copy paste it into your config
Nov 11 11:48:12 <lsmith>	jwage: for example lifecyclecallbacks
Nov 11 11:48:20 <avalanche123>	Seldaek, you would usualle overload some parameters and service definitions
Nov 11 11:48:21 <henrikbjorn>	with form validation it is a big problem
Nov 11 11:48:24 <jmikola|w>	Seldaek: are you referring to modifying the bundle's XML?  couldn't you just load your own bundle with DIC YML config after the third-party one and redefine things?
Nov 11 11:48:32 <avalanche123>	you don't need the whole thing in yaml for that
Nov 11 11:48:52 <avalanche123>	also '@' in yaml for aliases breaks highlighting
Nov 11 11:49:04 <avalanche123>	im NetBeans at least
Nov 11 11:49:06 <fabpot>	are we talking about the config files or also about Doctrine / Validation / Routing files?
Nov 11 11:49:18 *	dljones ([email protected]) has joined #symfony-dev
Nov 11 11:49:19 <avalanche123>	fabpot, not me
Nov 11 11:49:22 <lsmith>	fabpot: everything imho
Nov 11 11:49:40 <avalanche123>	I only had app configs and DIC
Nov 11 11:49:42 <Seldaek>	jmikola|w, avalanche123, YES you can, but you're not listening :) I'm saying if you want to redefine a service, it'd be much easier to be able to copy paste it and then change a few things, than to have to write everything from scratch by reading the xml one
Nov 11 11:49:46 *	tijuan ([email protected]) has joined #symfony-dev
Nov 11 11:50:16 <avalanche123>	Seldaek, in that case maybe a conversion tool would be more helpful?
Nov 11 11:50:17 <lsmith>	and not everything can be handled by just "merging" the configs
Nov 11 11:50:31 <avalanche123>	some cli command to convert configs
Nov 11 11:50:35 <avalanche123>	?
Nov 11 11:50:38 <jmikola|w>	fabpot: i think the differences between app config, DI, doctrine, validation, routing are a bit broad to support just one format
Nov 11 11:50:41 <Seldaek>	avalanche123: yeah convert and then delete the converted file and extract what you need and lala.. I'd rather read xml:/
Nov 11 11:50:49 <avalanche123>	Seldaek:)
Nov 11 11:50:59 <jmikola|w>	lsmith: we have loaders and dumpers, at least for DI
Nov 11 11:51:02 <pgodel_work>	+1 some cli command to convert configs
Nov 11 11:51:02 *	mofoe333 ([email protected]) has left #symfony-dev
Nov 11 11:51:03 <lsmith>	and like i said i am still concerned about if its really be easy to support mixed configs .. seems like a lot of permutations allowing lots of bugs to slip through
Nov 11 11:51:12 *	yosmanyga has quit (Ping timeout: 276 seconds)
Nov 11 11:51:15 <everzet>	Seldaek: converter can output to console instead of dumping to file
Nov 11 11:51:24 <fabpot>	lsmith: definitely not a problem for the DIC configuration
Nov 11 11:51:27 <avalanche123>	everzet +1
Nov 11 11:51:32 <jmikola|w>	most of the other config types don't have dumpers for everything, just loaders, though - but we should be able to make a CLI command that loads/dumps DI configs now
Nov 11 11:51:40 <lsmith>	yeah .. i havent had issues with the DIC
Nov 11 11:52:07 <Seldaek>	everzet: yes of course, but I don't know.. I just don't see how xml is easier to define stuff than yaml, I don't see why you need complex structures in your services anyway, it's just a bunch of arguments
Nov 11 11:52:12 <lsmith>	one thing that Seldaek didnt mention yet .. there is a "standard" for validating YAML
Nov 11 11:52:23 <lsmith>	we could implement http://www.kuwata-lab.com/kwalify/
Nov 11 11:52:25 <lsmith>	in php ..
Nov 11 11:52:33 <avalanche123>	things is yaml is great for array style configs - stuff that DI extension use, but not great for hirarchical (hope I spelled it correctly) structures
Nov 11 11:52:33 <Seldaek>	imo the "complex strucutres" are just complex because they're written in xml
Nov 11 11:52:48 <avalanche123>	have you tries defining anonymous service argument?
Nov 11 11:52:48 <lsmith>	since there are already validators for ruby/java .. its also possible for most of the IDE's to support validation
Nov 11 11:52:49 <avalanche123>	in yaml
Nov 11 11:52:54 <Seldaek>	avalanche123: and what is hierarchical in DIC config?
Nov 11 11:52:54 <avalanche123>	*tried
Nov 11 11:52:59 <lsmith>	like netbeans, phpstorm
Nov 11 11:53:05 <fabpot>	avalanche123: it's not possible ;)
Nov 11 11:53:16 <avalanche123>	fabpot, exactly:)
Nov 11 11:53:18 <lsmith>	komodo afaik supports calling php stuff
Nov 11 11:53:20 <jmikola|w>	Seldaek: definitely anonymouse services with <call> blocks and such - things can get hairy quickly
Nov 11 11:53:25 <avalanche123>	DIC configs are hierarchical
Nov 11 11:53:28 <Seldaek>	avalanche123, fabpot: what about arguments: [ foo, bar], or arguments:\n - foo\n - bar
Nov 11 11:53:52 <avalanche123>	reads like ruby:)
Nov 11 11:53:53 <pgodel_work>	there was a set of slides in last SF meetup that showed the problem of using yaml for DIC - it was really confusing
Nov 11 11:54:07 <avalanche123>	*not readable
Nov 11 11:54:18 <everzet>	pgodel_work, avalanche123: +1
Nov 11 11:54:25 <jmikola|w>	pgodel_work: is it one of these? http://www.slideshare.net/fabpot
Nov 11 11:54:38 <jmikola|w>	^ see dep injection slides
Nov 11 11:54:43 *	lee1 has quit (Read error: Connection reset by peer)
Nov 11 11:54:47 <henrikbjorn>	seldeak maybe try and convert a core XML one to yaml for proff of concept?
Nov 11 11:54:48 <lsmith>	do you guys know the yaml merge key syntax? its supported by the yaml component and helps a lot http://yaml.org/type/merge.html
Nov 11 11:54:52 *	lee1 ([email protected]) has joined #symfony-dev
Nov 11 11:55:26 <Seldaek>	henrikbjorn: I will, any good candidate avalanche123 or any of the disbelievers ?:)
Nov 11 11:55:41 <henrikbjorn>	the Security one
Nov 11 11:55:41 *	Assassik ([email protected]) has left #symfony-dev
Nov 11 11:55:52 <Seldaek>	the security is mostly defined in the extension isn't it?
Nov 11 11:55:57 *	Kaos_ (512ccaf4@gateway/web/freenode/ip.81.44.202.244) has joined #symfony-dev
Nov 11 11:56:09 <Seldaek>	nah ok there is an xml
Nov 11 11:56:13 *	Kaos_ is now known as Caos
Nov 11 11:56:15 <Seldaek>	I'll happily convert that
Nov 11 11:56:18 <Caos>	Hi there
Nov 11 11:56:21 <fabpot>	Seldaek: the best example is "Enabling Custom Template Helpers" section of http://docs.symfony-reloaded.org/master/guides/templating/helpers.html
Nov 11 11:56:30 <fabpot>	YAML: services:
Nov 11 11:56:30 <fabpot>	    templating.helper.your_helper_name:
Nov 11 11:56:30 <fabpot>	        class: Fully\Qualified\Helper\Class\Name
Nov 11 11:56:31 <fabpot>	        tags:
Nov 11 11:56:31 <fabpot>	            - { name: templating.helper, alias: alias_name }
Nov 11 11:56:38 <fabpot>	XML: <service id="templating.helper.your_helper_name" class="Fully\Qualified\Helper\Class\Name">
Nov 11 11:56:39 <fabpot>	    <tag name="templating.helper" alias="alias_name" />
Nov 11 11:56:39 <fabpot>	</service>
Nov 11 11:56:48 <fabpot>	the confusing part is how you define tags in YAML
Nov 11 11:56:52 <avalanche123>	fabpot +1, I was looking for that one
Nov 11 11:57:05 <pgodel_work>	me too :)
Nov 11 11:57:17 <Seldaek>	fabpot: yes.. this could be the following though:
Nov 11 11:57:19 <fabpot>	lots of conventions (the -, the {}, the spaces, ...)
Nov 11 11:57:20 <Seldaek>	tags:
Nov 11 11:57:22 <Seldaek>	 - name: foo
Nov 11 11:57:28 <Seldaek>	   alias: bar
Nov 11 11:57:29 <lsmith>	oki .. we are through with this timebox
Nov 11 11:57:33 <jmikola|w>	i suppose the loader/dumper is smart enough to know the yml properties class/tags have to end up as an attribute and child tag, respectively?
Nov 11 11:57:37 <lsmith>	of course you can all continue to chat
Nov 11 11:57:44 <fabpot>	Seldaek: exactly, that' yet another pbe many different way to express the same thing with YAML
Nov 11 11:57:50 <avalanche123>	lsmith:)
Nov 11 11:57:53 <lsmith>	overall .. its been a bit humbling in what can be achieved via chat in 15mins
Nov 11 11:58:02 <lsmith>	but i still feel like its beneficial overall
Nov 11 11:58:13 <lsmith>	i will throw the irc log on the wiki
Nov 11 11:58:14 <pgodel_work>	lsmith: yes, very positive
Nov 11 11:58:21 <lsmith>	write an "instruction" thingi for the docs
Nov 11 11:58:33 <fabpot>	thank you all for this chat. I think this is really useful.
Nov 11 11:58:35 <lsmith>	and send out a summary with tickets for the different changes we agreed
Nov 11 11:58:40 <Seldaek>	fabpot: well anyway, I see there is too much resistance, so I guess I'll just drop the case, even though it saddens me a bit. Is there a way to validate the yaml extension configs from the bundle xsd though at least?
Nov 11 11:59:04 <fabpot>	Seldaek: I don't even know what you opinion is? YAML or XML?
Nov 11 11:59:07 <Seldaek>	because otherwise, this whole xml/xsd stuff is bullshit imo
Nov 11 11:59:21 <Seldaek>	fabpot: well, I'd rather go with yaml, if it wasn't clear:)
Nov 11 11:59:38 <fabpot>	Seldaek: well, so we think the same... at least for the app configuration
Nov 11 11:59:42 <lsmith>	Seldaek: http://redotheweb.com/2008/09/09/validating-a-yaml-file-against-a-schema-in-php/
Nov 11 11:59:56 <fabpot>	lsmith: please...
Nov 11 12:00:15 <Seldaek>	fabpot: well,the agreement seems to be yaml for app config, and xml for the rest
Nov 11 12:00:21 <Seldaek>	that means the xsd go away ?
Nov 11 12:00:22 <everzet>	Seldaek: +1
Nov 11 12:00:23 <mahono>	imho when there is a way to validate yaml we should drop everything else and keep using yaml with Symfony2
Nov 11 12:00:33 <avalanche123>	I prefer yaml for routing btw
Nov 11 12:00:39 <everzet>	avalanche123: +1
Nov 11 12:00:43 <Seldaek>	because the xsd is only used to validate the app config right?
Nov 11 12:00:50 <Seldaek>	so if it's never gonna be in xml, fuck it
Nov 11 12:01:01 *	naderman (~naderman@phpbb/manager/naderman) has joined #symfony-dev
Nov 11 12:01:03 <jmikola|w>	mahono: i think the link lsmith posted is worth looking into - a tool to validate app configs (even in yml) would be helpful
Nov 11 12:01:16 <Seldaek>	that would let us remove those two pointless methods on the Extension that are xml specific too..
Nov 11 12:01:18 <jmikola|w>	the downside being that bundle devs would need to all write proper xsd's :)
Nov 11 12:01:23 <fabpot>	Seldaek: what are you talking about?
Nov 11 12:01:35 <fabpot>	XSD is about validation, completion, and documentation
Nov 11 12:01:36 <Seldaek>	fabpot: that if you do a typo in your app config, you don't get any warning
Nov 11 12:01:52 <fabpot>	ok, need to go now. thanks and talk to you all next week
Nov 11 12:02:03 <Seldaek>	meh.. ok cya
Nov 11 12:02:04 <avalanche123>	fabpot, thanks!
Nov 11 12:02:10 <everzet>	fabpot: thanks!
Nov 11 12:02:11 *	fabpot has quit (Quit: fabpot)
Nov 11 12:02:12 <pgodel_work>	thanks all
Nov 11 12:02:13 <avalanche123>	Seldaek, you could validate that in the extension
Nov 11 12:02:23 <avalanche123>	and throw exception, no?
Nov 11 12:02:29 *	IamPersistent has quit (Quit: Bye)
Nov 11 12:02:43 <Seldaek>	avalanche123: so you want everyone to implement their own validation?
Nov 11 12:02:44 <jmikola|w>	avalanche123: the way many extensions are written, invalid things get ignored :)
Nov 11 12:03:02 <Seldaek>	avalanche123: also, if we do that, imo it means XSDs are pointless
Nov 11 12:03:06 *	juvabien (5138322d@gateway/web/freenode/ip.81.56.50.45) has left #symfony-dev
Nov 11 12:03:07 <mahono>	as yaml validation is probably only a hack it is probably better to use a standard and use xml...
Nov 11 12:03:14 <avalanche123>	Seldaek, yeah, they would still have to - wether its XSD or exceptions:)
Nov 11 12:03:25 <avalanche123>	jmikola|w, that's a different issue
Nov 11 12:03:34 <jmikola|w>	Seldaek: what are your thoughts on using XSD's to attempt yml app config validation?
Nov 11 12:03:37 <Seldaek>	avalanche123: well, in XSD you just define the schema, you don't have to write as much code as to validate everything imo
Nov 11 12:03:44 <everzet>	avalanche123: i think Seldaek just wants to kill something XMLish in Symfony today =)))
Nov 11 12:03:49 <avalanche123>	haha:)
Nov 11 12:03:58 <avalanche123>	XML imo is not a bad thing always
Nov 11 12:03:59 <Seldaek>	jmikola|w: I'd rather impelment kwalify in php and define the schemas in yaml..
Nov 11 12:04:17 <avalanche123>	Seldaek, maybe something line form options?
Nov 11 12:04:28 <avalanche123>	in the Form component you can say which options are required
Nov 11 12:04:29 *	Garfield-fr ([email protected]) has joined #symfony-dev
Nov 11 12:04:38 <naderman>	why reinvent the wheel to get something in the end that is not superior to what you can already get today?
Nov 11 12:04:39 <Seldaek>	avalanche123: maybe, but that doesn't scale well with nested options and complex types
Nov 11 12:05:01 <Seldaek>	naderman: a yaml schema/validator could be useful for other things
Nov 11 12:05:12 *	Bouke ([email protected]) has left #symfony-dev
Nov 11 12:05:13 <Seldaek>	and I don't want to reinvent, just implement some existing stuff in php
Nov 11 12:05:16 <avalanche123>	Seldaek, agree about nested options
Nov 11 12:05:17 <naderman>	not if you avoid yaml
Nov 11 12:05:35 <avalanche123>	so my opinion is that Extension should validate its options
Nov 11 12:05:43 <avalanche123>	as a best practice
Nov 11 12:05:44 <Seldaek>	naderman: yeah then you just annoy every user with xml configs, and those that don't use will laugh at us for using xml :)
Nov 11 12:05:59 <avalanche123>	naderman, xml doesn't work everywhere
Nov 11 12:06:04 <naderman>	people laugh at you for using yaml too
Nov 11 12:06:11 <naderman>	so that's really a pretty poor argument
Nov 11 12:06:12 <pgodel_work>	:)
Nov 11 12:06:18 <everzet>	avalanche123: in that case, XSD is definetly useless
Nov 11 12:06:22 <avalanche123>	but Seldaek, if you need to validate unstructured format agains a schema - you're doing something wrong
Nov 11 12:06:26 *	craigj ([email protected]) has joined #symfony-dev
Nov 11 12:06:29 *	JayExercise (45aaa08a@gateway/web/freenode/ip.69.170.160.138) has joined #symfony-dev
Nov 11 12:06:45 <naderman>	avalanche123: sure, but are there places that need validation where it does not work?
Nov 11 12:06:52 <naderman>	exactly avalanche123
Nov 11 12:06:54 <avalanche123>	naderman, agreed
Nov 11 12:07:03 <avalanche123>	so it should be done in a separate layer
Nov 11 12:07:04 <Seldaek>	avalanche123: well, I don't personally care, I don't do that many typos
Nov 11 12:07:10 <avalanche123>	haha:)
Nov 11 12:07:14 <avalanche123>	I understand
Nov 11 12:07:23 *	henrikbjorn has quit (Ping timeout: 240 seconds)
Nov 11 12:07:23 *	FabienPomerol has quit (Quit: Page closed)
Nov 11 12:07:24 <avalanche123>	just saying that for every job there is the best tool
Nov 11 12:07:30 <Seldaek>	it's just that I've seen enough people shooting themselves in the foot and looking at weird errors for hours because of a typo in the config
Nov 11 12:07:40 <avalanche123>	yeah
Nov 11 12:07:42 <Seldaek>	so I think it'd be beneficial to validate stuff
Nov 11 12:07:52 <avalanche123>	absolutely, just in a different layer
Nov 11 12:07:54 <naderman>	what else did I miss btw? fell asleep on the couch before the meeting started ;-)
Nov 11 12:08:04 <avalanche123>	naderman, haha:)
Nov 11 12:08:08 <avalanche123>	lsmith will post logs
Nov 11 12:08:10 <pgodel_work>	naderman: there will be a  log online
Nov 11 12:08:16 <naderman>	ah ok