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

transcript.txt

Jan 13 10:59:42 <lsmith>	fabpot: ping
Jan 13 11:00:09 <lsmith>	first topic would be you -> Roadmap until Symfony2 stable release
Jan 13 11:00:35 <lsmith>	johanness: ping
Jan 13 11:00:46 <johanness>	yeah?
Jan 13 11:00:50 <johanness>	can't comment on this :)
Jan 13 11:01:07 <fabpot>	ok
Jan 13 11:01:21 <fabpot>	we need to stabilize the Symfony2 API
Jan 13 11:01:39 <fabpot>	like it or not, but like I said last week, we need to try to release Symfony2 final March 6th
Jan 13 11:01:44 <fabpot>	which is in less than 2 months!
Jan 13 11:02:06 <fabpot>	so, I propose to have some main topics for each week until the first RC to stabilize the API
Jan 13 11:02:23 <fabpot>	to have a good base, I will release a PR tomorrow with a sandbox
Jan 13 11:02:31 <fabpot>	February 5-
Jan 13 11:02:42 <fabpot>	and 6, we will have 2 hacking days
Jan 13 11:02:58 <fabpot>	February 6th: the release of the first Symfony2 RC
Jan 13 11:03:10 <fabpot>	another hacking day March 5th
Jan 13 11:03:23 <fabpot>	the hacking days will take place in SF and Paris, but also online of course
Jan 13 11:03:26 <lsmith>	i guess we can try to incorporate people virtually to those hackdays
Jan 13 11:04:02 <fabpot>	So, instead of working on everything, I want to have some guidelines so that many people can help us
Jan 13 11:04:11 <lsmith>	i guess at the hackdays one big area that people can "easily" get involved in is expanding the testing
Jan 13 11:04:13 <pgodel_work>	are you going to propose topics for the hacking days, is there going to be an agenda ?
Jan 13 11:04:39 <lsmith>	we will just need to organize things a bit to prevent redundant efforts
Jan 13 11:04:40 <fabpot>	after some talks with Johannes, Bernhard, Jonathan, and Benjamin, here is a tentative schedule
Jan 13 11:04:58 <fabpot>	oh, before that
Jan 13 11:05:14 <fabpot>	I think we have 3 main big components that requires special attention
Jan 13 11:05:18 <fabpot>	Form/Validator/Locale
Jan 13 11:05:22 <fabpot>	Doctrine*Bundle
Jan 13 11:05:24 <fabpot>	Security
Jan 13 11:05:58 <lsmith>	in security i assume you are including ACL
Jan 13 11:06:03 <fabpot>	lsmith: yes
Jan 13 11:06:12 *	rouffj_ (~rouffj@seg75-2-89-80-223-180.dsl.club-internet.fr) has joined #symfony-dev
Jan 13 11:06:15 *	aramirez (~Adium@84.125.223.70.dyn.user.ono.com) has joined #symfony-dev
Jan 13 11:06:29 <fabpot>	so, next week for instance, we will focus our tests and work on the Security component
Jan 13 11:06:30 <lsmith>	Form/Validator/Locale you mean removing the intl dependency?
Jan 13 11:06:44 <fabpot>	lsmith: I mean everything related to these 3 components
Jan 13 11:06:49 <lsmith>	k
Jan 13 11:06:50 <fabpot>	removing the intl dependency is just one thing
Jan 13 11:07:07 <fabpot>	the week after, Form/Validator/Locale
Jan 13 11:07:09 <pgodel_work>	that may be the biggest of all 3
Jan 13 11:07:16 <fabpot>	and then the Doctrine bundles
Jan 13 11:07:55 <Seldaek>	I'd love it if we could remove intl altogether, I don't like it, but I'm not sure what other options are there besides ZF stuff
Jan 13 11:07:56 <fabpot>	So, I will write a post for the Symfony blog, and I want t opublish it tomorrow with the new Preview Release
Jan 13 11:08:19 <fabpot>	Seldaek: my point of view is that we cannot have a hard dependency with intl
Jan 13 11:08:28 <fabpot>	forms should work without the intl extension
Jan 13 11:08:35 <lsmith>	fabpot: how do we track the open issues and responsibilities?
Jan 13 11:08:37 <fabpot>	in which case, you will loose some abilities of course
Jan 13 11:08:38 <Seldaek>	yeah, obviously.. but we need to see what is working and what is not if intl is missing
Jan 13 11:08:58 <fabpot>	In my post, I will name the people in charge of each main components
Jan 13 11:09:04 <fabpot>	So, for forms, it's Bernhard
Jan 13 11:09:04 <lsmith>	also we need to push towards closing tickets on http://trac.symfony-project.org/report/24
Jan 13 11:09:11 <fabpot>	for Doctrine, Jonathan and Benjamin
Jan 13 11:09:17 <fabpot>	for Security, Johannes and myself
Jan 13 11:09:45 <lsmith>	fabpot: yeah ... but how do we know what to work on specifically? how to we prevent duplicate efforts?
Jan 13 11:10:05 <fabpot>	lsmith: the goal is to test the components on real-life situations
Jan 13 11:10:07 <fabpot>	to add unit tests
Jan 13 11:10:10 <fabpot>	to validate the API
Jan 13 11:10:21 <fabpot>	and to finish major missing features
Jan 13 11:10:37 <fabpot>	I think validating the API is the biggest work
Jan 13 11:10:51 <fabpot>	fixing bugs can be done after RC, changing the API won't be an option
Jan 13 11:11:05 <Seldaek>	fabpot: also, can you make sure bernhard is really available the week of the form stuff, because he tends to be hard to reach and he is a single point of failure for Forms questions
Jan 13 11:11:12 <lsmith>	right .. for the later .. for security i see: rememberme, cleartext password in session, adding csrf to form login as open issues for example
Jan 13 11:11:37 <lsmith>	Seldaek: well in that week .. he will actually be in the liip offices :)
Jan 13 11:11:43 <Seldaek>	ok goody
Jan 13 11:12:12 <fabpot>	Seldaek: well, Sensio supports his work on the form framework, that's all I can do
Jan 13 11:12:21 <fabpot>	I think he has other things to do as well
Jan 13 11:12:36 <Seldaek>	fabpot: yeah no worry, but if he's in the liip office then you can put me as secondary contact, I'll make sure he answers :P
Jan 13 11:12:48 <fabpot>	that's great!
Jan 13 11:13:32 <Seldaek>	next?
Jan 13 11:13:36 <lsmith>	anything else? ah i will go through meeting summaries .. looking for decisions taken .. that havent been implemented yet
Jan 13 11:13:49 <Seldaek>	yeah that'd be great
Jan 13 11:13:58 <fabpot>	perhaps one last thing
Jan 13 11:13:59 <lsmith>	reminding people that promised to work on stuff
Jan 13 11:14:04 <fabpot>	so that it's clear for everybody
Jan 13 11:14:06 <Seldaek>	watching for topics on the ml that have had no answers might be good too, but takes time
Jan 13 11:14:13 <fabpot>	after RC1, we will need to keep BC
Jan 13 11:14:50 <avalanche123>	I think that Request object needs to be revisited too
Jan 13 11:14:51 <fabpot>	so, if you think that some APIs are broken, you still have 3 weeks
Jan 13 11:14:55 <avalanche123>	I have a couple of ideas
Jan 13 11:14:58 <avalanche123>	will email
Jan 13 11:14:59 <fabpot>	avalanche123: agree
Jan 13 11:15:00 *	rooster hates that he has to leave - but will catch up with the summary later...
Jan 13 11:15:00 <lsmith>	someone should also setup PHP_CodeSniffer checking .. stuff like phpdoc and CS stuff
Jan 13 11:15:04 <avalanche123>	been very busy recently
Jan 13 11:15:10 <lsmith>	another area where people can easily help on the hackdays
Jan 13 11:15:32 <pgodel_work>	lsmith: good idea
Jan 13 11:15:35 <Seldaek>	lsmith: that's easy to fix later though
Jan 13 11:15:47 <avalanche123>	https://github.com/opensky/Symfony2-coding-standard
Jan 13 11:15:47 <Seldaek>	let's break all the BC we can in the next 3 weeks :)
Jan 13 11:15:48 <lsmith>	Seldaek: of course .. but later isnt that much longer :)
Jan 13 11:16:06 *	rooster has quit (Read error: Connection reset by peer)
Jan 13 11:16:08 <lsmith>	ok .. moving on?
Jan 13 11:16:25 <lsmith>	credentials serialized in clear text: http://bit.ly/h07nB4
Jan 13 11:16:38 <lsmith>	i noticed that the session file's contain the clear text password
Jan 13 11:16:47 <lsmith>	even if password hashing is enabled
Jan 13 11:17:03 <Seldaek>	yeah that sounds unacceptable
Jan 13 11:17:08 <lsmith>	is there a reason for this? and if so .. we need to remove it :)
Jan 13 11:17:17 <jmikola|w>	shouldn't eraseCredentials() be stripping that out?
Jan 13 11:17:34 <fabpot>	sound like a bug
Jan 13 11:17:36 <johanness>	it's not a major issue, and spring actually introduced erasing credentials only fairly recently
Jan 13 11:17:36 <fabpot>	sounds*
Jan 13 11:17:36 <Seldaek>	yeah but the passwords shouldn't be stored on the user object either
Jan 13 11:17:37 *	rande has quit (Read error: Connection reset by peer)
Jan 13 11:17:48 <johanness>	my pull request with the shared authentication manager fixes this as well
Jan 13 11:17:51 <Seldaek>	they should be hashed ASAP and forgotten
Jan 13 11:18:07 <avalanche123>	Seldaek +1
Jan 13 11:18:31 <Seldaek>	otherwise it's just a disaster waiting to happen, especially if it depends on users writing some function to clean up sensitive data
Jan 13 11:18:51 <lsmith>	fabpot: when i checked .. the code seemed to rely on being able to rehash the password during subsequent requests after login ..
Jan 13 11:19:19 <lsmith>	ok .. then i will just note down that this issue needs to be addressed and is not something we will accept ..
Jan 13 11:19:36 <lsmith>	so i guess we can move to the next topic
Jan 13 11:19:45 <lsmith>	Suggested changes to default rendering of forms: http://bit.ly/eG4kbF
Jan 13 11:19:49 <lsmith>	tom doesnt seem to be around ..
Jan 13 11:20:16 <lsmith>	from my understanding he was suggesting to make the out of the box form's more "useful"
Jan 13 11:20:35 <lsmith>	while fabien made it clear that its easy to selectively override the defaults via the form theming
Jan 13 11:20:49 <pgodel_work>	checking if Tom can login
Jan 13 11:20:50 <lsmith>	maybe one of the people who voted on this topic has something to say?
Jan 13 11:21:07 <lsmith>	weaverryan, avalanche123, pgodel_work?
Jan 13 11:21:15 <weaverryan>	lsmith: yea, just getting here
Jan 13 11:21:18 <jmikola|w>	i thought the sf_ prefixes would be ripe for an admin generator bundle, that would likely provide base CSS as well
Jan 13 11:21:21 <fabpot>	I think that it makes sense to have something that can describe the layout of a form, but that's different from the default form template
Jan 13 11:21:29 <weaverryan>	we may need to shelf it - I haven't had enough time to study it, but I'm studying it now
Jan 13 11:21:50 *	Dominique__ (~chatzilla@AToulouse-152-1-43-204.w82-125.abo.wanadoo.fr) has joined #symfony-dev
Jan 13 11:21:59 <avalanche123>	well, I though just ading classes and ids to default form rendering should work
Jan 13 11:22:07 <avalanche123>	not in the field rendering functions though
Jan 13 11:22:14 <avalanche123>	but onle when they render the whole form
Jan 13 11:22:20 <avalanche123>	*only
Jan 13 11:22:24 <jmikola|w>	i don't see the benefit of adding class names unless sf2 was going to ship with some default CSS
Jan 13 11:22:30 <pgodel_work>	I agree in general with Tom that some form of default classes would help a lot, and as long it can be changed it should not hurt at all
Jan 13 11:22:35 <jmikola|w>	otherwise, that's added documentation just to tell the user what elements to style themselves
Jan 13 11:22:59 <avalanche123>	jmikola|w, like I said, only if they use form_render(form)
Jan 13 11:23:00 <fabpot>	avalanche123: the problem is that if we start adding classes and ids, people will want to keep that and will ask for more flexibility
Jan 13 11:23:14 <fabpot>	like being able to put fields side by side instead of one after the other, ...
Jan 13 11:23:18 <avalanche123>	fabpot I see your point
Jan 13 11:23:19 <lsmith>	jmikola|w: well there is now a bit of a chance that for the stable release there will be an admin generator bundle
Jan 13 11:23:26 <Seldaek>	jmikola|w: default class names, if they're not sf_ prefixed, could be useful imo, makes it easier to hook your css into it without the need for custom form templates. But then again, I haven't needed to modify form templates yet..
Jan 13 11:23:34 <Seldaek>	usually a class on the form element itself is enough
Jan 13 11:23:34 <jmikola|w>	tom's suggestion about not having naked text nodes made sense though... at the very least we can add <span>'s
Jan 13 11:23:35 <pgodel_work>	fabpot: but don't you think this is repeating work that needs to be done most of the time you are dealing with forms ?
Jan 13 11:23:53 <avalanche123>	I think its not necessary to make it part of the framework
Jan 13 11:23:53 <lsmith>	thomas and bernhard will be collaborating to push https://github.com/sonata-project/BaseApplicationBundle forward
Jan 13 11:24:00 *	boutell (~boutell@75-150-180-10-Philadelphia.hfc.comcastbusiness.net) has joined #symfony-dev
Jan 13 11:24:02 <Seldaek>	jmikola|w: no that's insane, wrap the entire selects into a <p> or whatever, but not a comma wrapped in a <span>.. :)
Jan 13 11:24:13 <fabpot>	pgodel_work: when was the last time you used that to output a form? my answer is never
Jan 13 11:24:18 <avalanche123>	we could make it a LazyFormsBundle
Jan 13 11:24:19 <boutell>	Hey, the troublemaker who wrote that post to symfony-devs is here (:
Jan 13 11:24:36 <Herzult>	I think a good documentation on how create a custom theme is sufficient
Jan 13 11:24:58 <Seldaek>	Herzult: yeah, I'd tend to agree
Jan 13 11:25:03 <avalanche123>	Herzult +1
Jan 13 11:25:08 <avalanche123>	fabpot I concur:)
Jan 13 11:25:26 <Seldaek>	with one class on the <form> tag, you don't really need classes all over the place inside
Jan 13 11:25:31 <Seldaek>	there are tag names and attributes already
Jan 13 11:25:32 <lsmith>	right .. there will likely be form theme bundles
Jan 13 11:25:39 <weaverryan>	I haven't looked into the forms yet, so as long as it's the "pluggable" so that I can easily share my themes, etc
Jan 13 11:25:45 <boutell>	Seldaek: that's not sufficient to target most things.
Jan 13 11:25:48 <boutell>	are there any front end devs here
Jan 13 11:25:55 <boutell>	or is this a bunch of back end PHP guys arguing about what front end devs want
Jan 13 11:25:59 <Seldaek>	boutell: well I haven't had any problems so far styling stuff
Jan 13 11:26:12 <fabpot>	boutell: my point is not to say that there is no value in adding classes and ids but that's this is the wrong place to do so
Jan 13 11:26:13 <Seldaek>	boutell: I'd consider myself well versed in css ..
Jan 13 11:26:14 <boutell>	Seldaek: CSS cannot target a checkbox by itself
Jan 13 11:26:20 <lsmith>	we have done some changes to our form's .. adding some classes etc
Jan 13 11:26:28 <Seldaek>	boutell: input[type="checkbox"] ?
Jan 13 11:26:35 <lsmith>	all via the theming
Jan 13 11:26:51 <boutell>	Seldaek: pardon, if you're concerned about IE6 bc you can't
Jan 13 11:27:04 <Seldaek>	yeah well, I'm not, not for the styles of a checkbox
Jan 13 11:27:12 <lsmith>	for example http://pastebin.com/Pvm9ePfT
Jan 13 11:27:29 *	rande (~Adium@darkstar2.fullsix.com) has joined #symfony-dev
Jan 13 11:27:33 <Seldaek>	boutell: but then you can just use a ie6_forms.twig
Jan 13 11:27:43 <Seldaek>	seriously IE6 is not a major concern anymore for many people
Jan 13 11:27:48 <pgodel_work>	how do other frameworks deal with this, if any ?
Jan 13 11:27:52 <boutell>	fabpot: how does one theme forms in such a way that your theme applies to all forms that aren't being explicitly themed to the contrary? For instance if there's a form being "just rendered" in some bundle in your project, will it respect your theme?
Jan 13 11:27:57 <Seldaek>	I recognize it's not off the grid entirely, but we shouldn't build with it in mind in the framework
Jan 13 11:27:59 <mvrhov>	well he can just wrap form in a div and give that div a class then he can style..
Jan 13 11:28:10 <lsmith>	boutell: you can set a theme inside your form class
Jan 13 11:28:22 <fabpot>	boutell: this is configurable, yes. I think it's described in the documentation as well.
Jan 13 11:28:33 <lsmith>	and you can also set a global theme
Jan 13 11:28:41 <boutell>	lsmith: I am asking whether, for a particular project, I can get the same effect I would get if I could convince fabpot to accept my changes to the defaults. It sounds like a global theme does that.
Jan 13 11:28:44 <Seldaek>	boutell: you can override the form templates on a project basis, so it's no problem if the bundle comes with a form..
Jan 13 11:29:03 <Seldaek>	since the form itself doesn't define its rendering
Jan 13 11:29:07 <boutell>	how do I go about overriding the markup of DateField globally?
Jan 13 11:29:10 <lsmith>	boutell: yes, a global lets you selectively replace the standard form.twig
Jan 13 11:29:20 <Seldaek>	boutell: you override the date_field block in the form.twig
Jan 13 11:29:24 <lsmith>	the link i just pasted just overrides a few blocks ..
Jan 13 11:29:29 <lsmith>	but you can of course override all of them ..
Jan 13 11:29:41 <lsmith>	and you can of course also leave out the extends
Jan 13 11:30:22 <mvrhov>	as other framewroks go.. comming from the Zend one.. it assigns a class to the form element
Jan 13 11:30:24 <fabpot>	boutell: yes, all these things are possible
Jan 13 11:30:27 <lsmith>	https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/TwigBundle/Resources/views/form.twig
Jan 13 11:30:44 <lsmith>	each of these blocks can be overridden individually
Jan 13 11:30:47 <boutell>	lsmith: so how do I configure the project to use this override of form.twig?
Jan 13 11:31:08 <pgodel_work>	mvrhov: I was thinking more in terms of frameworks that are more considerate with UI. ZF is not much of it
Jan 13 11:31:13 <lsmith>	twig.config:
Jan 13 11:31:13 <lsmith>	    form:
Jan 13 11:31:13 <lsmith>	        resources: ['FooBundle::form.twig']
Jan 13 11:31:27 <Seldaek>	boutell: can we agree you'll look it up later and skip to the next issue? :)
Jan 13 11:31:30 <boutell>	lsmith: huh. I don't have to say what I'm replacing with it?
Jan 13 11:31:34 <boutell>	Seldaek: yes.
Jan 13 11:31:49 <boutell>	fair enough. I'm new to this channel but I get that it's not the howto channel, if it can be done that's all I should be asking here
Jan 13 11:31:53 <avalanche123>	boutell http://docs.symfony-reloaded.org/guides/forms/view.html
Jan 13 11:31:59 <Stof>	boutell: the TwigBundle one will stau here as a fallback
Jan 13 11:32:11 <Stof>	but if you define all the blocks it will never be used
Jan 13 11:32:13 <lsmith>	boutell: its a how to channel .. not necessarily during the meeting :)
Jan 13 11:32:17 <Seldaek>	boutell: I don't mind helping you later, just don't want to "waste" the 1h time slot on support :)
Jan 13 11:32:20 <lsmith>	ok next topic
Jan 13 11:32:22 <lsmith>	RFC for DIC template syntax: http://bit.ly/fAmNKo
Jan 13 11:32:23 <boutell>	lsmith: OK. I got hauled in kind of randomly (:
Jan 13 11:32:53 <lsmith>	so the point of this RFC is to make it possible to reuse and override templates within an XML/YAML config
Jan 13 11:33:20 <lsmith>	johanness put it best
Jan 13 11:33:27 <lsmith>	I think what you are looking for is the equivalent of
Jan 13 11:33:27 <lsmith>	$definition = clone $container->getDefinition();
Jan 13 11:33:27 <lsmith>	$arguments = $definition->getArguments();
Jan 13 11:33:27 <lsmith>	$arguments[3] = $sth;
Jan 13 11:33:27 <lsmith>	$definition->setArguments($arguments);
Jan 13 11:33:27 <lsmith>	$container->setDefinition('new.id', $definition);
Jan 13 11:33:28 <lsmith>	for XML, and YML
Jan 13 11:33:37 <lsmith>	however there is one more bit ..
Jan 13 11:33:51 <lsmith>	i want the name of the service to be derived from the things changed in the definition
Jan 13 11:34:09 <lsmith>	so that if i override a template in different bundles with the same argument changes
Jan 13 11:34:15 <lsmith>	i only end up with one service in the DIC
Jan 13 11:34:20 <johanness>	does that make sense? how would you use this service then?
Jan 13 11:34:26 <johanness>	if you don't know its id
Jan 13 11:34:41 <lsmith>	johanness: look at the example i gave http://groups.google.com/group/symfony-devs/browse_thread/thread/f136aec3d61fbbcc#
Jan 13 11:34:57 <lsmith>	    MyDefault:
Jan 13 11:34:57 <lsmith>	        class: Application\MyBundle\Controller\DefaultController
Jan 13 11:34:57 <lsmith>	        arguments:
Jan 13 11:34:57 <lsmith>	            view: @MyService [ fourth: 'this is just a test' ]
Jan 13 11:34:57 <lsmith>	        shared: true
Jan 13 11:35:15 <lsmith>	this would take the @MyService template
Jan 13 11:35:27 <johanness>	ah ok you define it inline
Jan 13 11:35:29 <lsmith>	and override the argument 'fourth' with 'this is just a test'
Jan 13 11:35:32 <lsmith>	yes
Jan 13 11:35:44 <lsmith>	and i dont need to know if the same thing is done else where
Jan 13 11:35:46 <lsmith>	or not
Jan 13 11:36:03 <lsmith>	it just does an md5() of the of the arguments
Jan 13 11:36:18 <lsmith>	this is useful when one has to define multiple very similar services
Jan 13 11:36:34 <johanness>	we could set it inline, don't need an id at all in this case
Jan 13 11:36:40 <lsmith>	johanness: ok
Jan 13 11:36:53 <lsmith>	yeah my proposal predates your work on inlining
Jan 13 11:37:05 <lsmith>	so the question is just .. do people think this would be useful?
Jan 13 11:37:26 <lsmith>	one use case is for people that do constructor injection
Jan 13 11:37:44 <lsmith>	and that always have to inject the same services for templating, emailing etc
Jan 13 11:37:56 <lsmith>	and then now and then a different repository depending on the controller
Jan 13 11:38:11 <fabpot>	lsmith: why not use interface injection?
Jan 13 11:38:14 <lsmith>	so they could define a controller template with defaults
Jan 13 11:38:25 <lsmith>	fabpot: interface injection has a serious flaw
Jan 13 11:38:37 <fabpot>	lsmith: ok, why not fix the flaw then
Jan 13 11:38:45 <fabpot>	what is the flaw?
Jan 13 11:38:50 <lsmith>	it means you bind your controller implementation to a specific service name
Jan 13 11:38:57 <lsmith>	fabpot: that flaw is by design
Jan 13 11:39:14 <lsmith>	aka if i implement interface X which injects the service id foobar
Jan 13 11:39:29 <lsmith>	then if i want to change the class for service id foobar .. then i will change it for all my controllers
Jan 13 11:39:37 <jmikola|w>	lsmith: it expects that foobar is the service providing that interface for your entire application
Jan 13 11:39:39 <lsmith>	so i loose a lot of flexibility ..
Jan 13 11:39:58 *	AlHornair has quit (Quit: Ex-Chat)
Jan 13 11:40:10 <lsmith>	this is the reason why i have always been advocating against injecting the container
Jan 13 11:41:13 <lsmith>	i can try to work on this .. but only if we have universal agreement on the principle
Jan 13 11:41:23 <jmikola|w>	regarding the previous code example, i can see why the "fourth: arg" thing could be convenient, but i'm comfortable with how the DIC factories for from Security component
Jan 13 11:41:25 <lsmith>	to me it would be very useful
Jan 13 11:42:24 <lsmith>	jmikola|w: what do you mean with "how the DIC factories for from Security component" ?
Jan 13 11:42:39 <lsmith>	btw .. there is at most 5 mins left in this timebox
Jan 13 11:42:47 <jmikola|w>	Security component has its own service templates, which the factories clone definitions of
Jan 13 11:43:43 <lsmith>	so how would this principle be applied to those using constructor injection to inject a common set of services?
Jan 13 11:43:52 <lsmith>	they would implement a factory?
Jan 13 11:44:01 <lsmith>	which gets a list of service names?
Jan 13 11:44:19 <lsmith>	and parameters ..
Jan 13 11:45:10 <fabpot>	lsmith: as I said before, if we implement something like this (and I'm not convinced yet), you should have a look at Spring templates
Jan 13 11:46:21 *	iAsterisk has quit (Quit: Computer has gone to sleep.)
Jan 13 11:46:37 <lsmith>	fabpot: yeah i tried to google the topic once .. but didnt really find a good source .. then again i am not a spring expert .. so i probably didnt look in the right place
Jan 13 11:46:43 <lsmith>	but anyway .. enough of this topic
Jan 13 11:46:46 <lsmith>	moving on
Jan 13 11:46:48 <lsmith>	Design questions about the Symfony 2 routing and security model: http://bit.ly/gc6UcJ
Jan 13 11:46:54 <lsmith>	another boutell topic
Jan 13 11:47:05 <lsmith>	boutell: want to give us a short summary? or shall I
Jan 13 11:47:37 <lsmith>	ok then i will
Jan 13 11:47:51 <lsmith>	the gist of the issue is that since the firewall is totally separate from the Bundles
Jan 13 11:48:06 <lsmith>	and the routing is separate from the Controllers
Jan 13 11:48:30 <lsmith>	and the firewall working on uri's and not routes
Jan 13 11:48:41 <lsmith>	it means that changing the routes can have tricky effects
Jan 13 11:48:50 *	raulfraile has quit (Quit: Ex-Chat)
Jan 13 11:48:53 <lsmith>	it can lead to things being no longer secured that were before
Jan 13 11:49:16 <lsmith>	or when changing a route to use a uri pattern instead of get/post that the controller needs to be changed
Jan 13 11:49:37 <lsmith>	for the later one approach could be injecting the uri pattern variables also into the request ..
Jan 13 11:49:51 <lsmith>	so that controllers arent forced to pick these parameters up as method parameters
Jan 13 11:50:18 <lsmith>	for the firewall issue .. in sf1 the security settings were set on the actions in the module config
Jan 13 11:50:24 <lsmith>	so much for the summary
Jan 13 11:50:31 <lsmith>	anyone have opinions on this?
Jan 13 11:50:49 <fabpot>	lsmith: security and URLs aren't necesseraly tied together
Jan 13 11:50:57 <fabpot>	I like the way it is right now
Jan 13 11:51:07 <fabpot>	Routing is only a way to convert the path info to parameters, nothing more
Jan 13 11:51:28 <lsmith>	fabpot: so if an action requires being able to get a user object from the security context
Jan 13 11:51:35 <avalanche123>	git stat
Jan 13 11:51:37 <lsmith>	should that action check if the user is logged in?
Jan 13 11:51:38 <avalanche123>	err
Jan 13 11:51:39 <avalanche123>	sorry
Jan 13 11:51:48 <lsmith>	or should i just rely on the firewall being configured properly?
Jan 13 11:52:07 <fabpot>	you should rely on the firewall being configured properly
Jan 13 11:52:13 <lsmith>	k
Jan 13 11:52:22 <Herzult>	The firewall map is not mandatory configured to match url pattern
Jan 13 11:52:34 <lsmith>	and what if i redesign my routes .. to use more uri pattern variables .. is it acceptable that this requires changes in the controller?
Jan 13 11:52:43 <Herzult>	it can match controllers in exemple
Jan 13 11:53:08 <lsmith>	Herzult: ah it can? i guess that would reduce the issue quite a bi
Jan 13 11:53:09 <lsmith>	bit
Jan 13 11:53:32 <Herzult>	http://docs.symfony-reloaded.org/master/guides/security/authorization.html#matching-a-request
Jan 13 11:54:03 *	ornicar (~ornicar@182.235.195-77.rev.gaoland.net) has joined #symfony-dev
Jan 13 11:54:29 <lsmith>	ok .. so what about uri pattern variables
Jan 13 11:54:51 <lsmith>	should they also be passed as GET parameters to the request object?
Jan 13 11:55:08 <lsmith>	that way developers could forgoe using method parameters for them
Jan 13 11:55:16 <Seldaek>	lsmith: I'd say like you told me about using URLs in functional tests, changing URLs should be a big event ;)
Jan 13 11:55:18 <lsmith>	in order to make it easier to redesign the urls
Jan 13 11:55:44 <lsmith>	Seldaek: yeah .. here however its also a thing in regards to 3rd party controllers
Jan 13 11:56:02 <lsmith>	i guess we could say a best practice for 3rd party controllers is not to use uri pattern variables
Jan 13 11:56:09 <Seldaek>	yup and also security is at stake
Jan 13 11:56:58 <lsmith>	ok .. 3 more minutes
Jan 13 11:57:09 <lsmith>	anyone else habe comments on this topic?
Jan 13 11:57:19 <lsmith>	..
Jan 13 11:57:28 <lsmith>	otherwise .. thx for your attention ..
Jan 13 11:57:42 <avalanche123>	thank you