Development

IRCLogs20110113

You must first sign up to be able to contribute.

Summary

http://doodle.com/wxt3qrqshzmg6m2f

Roadmap until stable release

...

credentials serialized in clear text

...

Suggested changes to default rendering of forms

...

RFC for DIC template syntax

...

Design questions about the routing and security model

...

IRC logs

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