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

transcript.txt

Dec 09 11:03:10 <lsmith>	so i guess lets start with Service Container wrapper: http://bit.ly/eCg9r8
Dec 09 11:03:18 <fabpot>	if it's about the remember me feature, I can talk about it
Dec 09 11:03:40 <lsmith>	fabpot: he is also featured in 2 other topics
Dec 09 11:03:51 <fabpot>	basically, the patch has been merged in a branch on my repo: https://github.com/fabpot/symfony/tree/refreshUserAfterUnserializing
Dec 09 11:04:05 <fabpot>	but we still have some details to iron out before it lands into my master
Dec 09 11:04:18 <lsmith>	ok what are the biggest concerns?
Dec 09 11:04:23 <fabpot>	so, I will work with Jonhannes in the coming days to fix everything
Dec 09 11:04:24 <lsmith>	i will probably try out the patch in the next days
Dec 09 11:04:35 <fabpot>	no big concerns, just some interface tweaking
Dec 09 11:04:42 <lsmith>	because i really need it for a sprint review next thursday :)
Dec 09 11:04:47 <lsmith>	k
Dec 09 11:04:54 <fabpot>	I have added the first one in the comment of the pull request
Dec 09 11:05:01 <lsmith>	so i guess nothing more to discuss at this point
Dec 09 11:05:05 <lsmith>	unless someone has questions
Dec 09 11:05:06 <fabpot>	https://github.com/fabpot/symfony/pull/254
Dec 09 11:05:39 <henrikbjorn>	sounds good :)
Dec 09 11:05:41 <fabpot>	oops
Dec 09 11:05:52 <fabpot>	I mixed up two different things
Dec 09 11:06:01 <fabpot>	forget everything I have just said
Dec 09 11:06:12 <fabpot>	I need to sleep more
Dec 09 11:06:15 <lsmith>	:)
Dec 09 11:06:24 <kertz>	./forget --all
Dec 09 11:06:33 <lsmith>	you were talking about https://github.com/fabpot/symfony/pull/252
Dec 09 11:06:52 <fabpot>	yes
Dec 09 11:07:43 <lsmith>	so anything you can tell us about the rememberme thing?
Dec 09 11:07:51 *	mpiecko (mpiecko@HSI-KBW-109-192-054-025.hsi6.kabel-badenwuerttemberg.de) has joined #symfony-dev
Dec 09 11:08:31 *	lsmith pokes fabpot
Dec 09 11:08:46 <fabpot>	nope, I need to review the patch
Dec 09 11:09:04 <fabpot>	it looks good to me, but I need to work with it a bit more before merging it
Dec 09 11:09:10 <lsmith>	ok .. i guess johanness has updated the patch .. so i will likely test it out tomorrow
Dec 09 11:09:19 <lsmith>	yeah .. all his changes tend to be very large
Dec 09 11:09:25 <fabpot>	but the code is really similar to the Spring one, so it should be good
Dec 09 11:09:29 <Seldaek>	sorry guys, we had team-meeting here
Dec 09 11:09:54 <fabpot>	my only concern is that the impact is quite large, which is why I'm a bit hesitant
Dec 09 11:10:10 <lsmith>	ok cool .. personally i would appreciate it if these security changes could be a focus
Dec 09 11:10:33 <lsmith>	a lot of people are stumbling over issues from what i have gathered in this channel over the last 1-2 weeks
Dec 09 11:10:46 <henrikbjorn>	couldnt the remember me thing be added as a authentication listener that returns a RemembermeToken ? :)
Dec 09 11:11:06 <avalanche123>	how would remember me work with rest apis?
Dec 09 11:11:41 <Seldaek>	but anyways I've to run, I have no clue about the whole security component yet anyways so I can't be of assistance, but for the container wrapper you have my support lsmith FWIW :p
Dec 09 11:11:44 <mvrhov>	rest shouldn't use cookies :P
Dec 09 11:11:53 <avalanche123>	exactly
Dec 09 11:11:56 <mvrhov>	pardon rest api
Dec 09 11:12:06 <avalanche123>	so it won't work there
Dec 09 11:12:17 <lsmith>	avalanche123: well from my limited understanding of johanness's patch he is adding listener hooks
Dec 09 11:12:35 <pgodel_work>	a browser consuming a rest service (ajax) could use cookies
Dec 09 11:12:36 <lsmith>	so it should be possible to do whatever you need
Dec 09 11:12:40 <mvrhov>	for rest api I'd purpose authenticating with additional http headers but now i think i'm to oft
Dec 09 11:13:33 <pgodel_work>	our application does this and works very well
Dec 09 11:13:45 <fabpot>	REST == no cookies
Dec 09 11:13:55 <avalanche123>	I know that
Dec 09 11:13:56 <avalanche123>	I haven't worked with security much, but I want clients to be trated universaly, and if there needs to be client specific code - it should be and extension
Dec 09 11:13:59 <avalanche123>	*an
Dec 09 11:14:16 <fabpot>	the remember me feature makes no sense for a REST API
Dec 09 11:14:26 <pgodel_work>	fabpot: I agree on that
Dec 09 11:14:30 <avalanche123>	so should it be in the security core then?
Dec 09 11:15:05 <fabpot>	avalanche123: I'm not sure I understand the conclusion based on the current discussion
Dec 09 11:15:12 <pgodel_work>	I guess I was referring to session cookies not remember me style
Dec 09 11:15:34 <avalanche123>	I am not too familiar with the remember me implementation
Dec 09 11:15:42 <lsmith>	avalanche123: without these changes its not possible to do proper remember me
Dec 09 11:16:11 <avalanche123>	ok, I'll leave it to you to decide, since I'm not solving this problem right now
Dec 09 11:16:33 <lsmith>	avalanche123: read http://groups.google.com/group/symfony-devs/browse_thread/thread/1227af69d014951b/08a803ea6d9c10fc#08a803ea6d9c10fc
Dec 09 11:16:39 *	wissl (~wissl@host-88-217-136-167.customer.m-online.net) has joined #symfony-dev
Dec 09 11:16:39 <avalanche123>	just wanted to make sure we're considering all cases
Dec 09 11:16:46 *	everzet (~everzet@mm-164-247-57-86.leased.line.mgts.by) has joined #symfony-dev
Dec 09 11:16:46 <lsmith>	johannes's comments will shed some light on things
Dec 09 11:16:54 <lsmith>	ok .. moving on to the container wrapper
Dec 09 11:17:22 <lsmith>	last week the discussed the issue of expensive dependencies being an issue for people that use explicit injection
Dec 09 11:17:35 <lsmith>	of course those who inject the container do not have these issues
Dec 09 11:17:48 <lsmith>	as for optinal services they incurr no penalties
Dec 09 11:18:06 <lsmith>	here at liip we do not like the idea of injecting the container
Dec 09 11:18:15 <lsmith>	since it means that you have no clue what the dependencies actually are
Dec 09 11:18:33 <lsmith>	which is why i began exploring the idea of making it optionally possible to have a wrapper around the container
Dec 09 11:18:49 <lsmith>	which you can tell which dependencies to actually allow to be requested
Dec 09 11:19:09 <lsmith>	furthermore it also addresses the issue of being able to change dependencies on a per class basis
Dec 09 11:19:30 <lsmith>	aka .. $this->container->get('mailer') returning something different in different controllers
Dec 09 11:19:39 <lsmith>	here is the code http://pastie.org/1349622
Dec 09 11:19:44 <henrikbjorn>	but injecting a wrapper for the dependency container how would that solve the issue? then you just inject a container wrapper instead of the container
Dec 09 11:19:48 <lsmith>	the beauty is that it could "unify" the world a bit
Dec 09 11:19:58 <lsmith>	aka those who dont care .. just inject the container as it is today
Dec 09 11:20:00 <lsmith>	and those who do
Dec 09 11:20:11 <lsmith>	have an out of the box solution to control things
Dec 09 11:20:19 <lsmith>	henrikbjorn: yes
Dec 09 11:20:29 <lsmith>	the main problem i see is how to define the wrapper service
Dec 09 11:20:37 <henrikbjorn>	and you would still dont really know the dependencies because they are in a config instead of the controller
Dec 09 11:20:39 <lsmith>	http://groups.google.com/group/symfony-devs/msg/d10f47ba55a75902
Dec 09 11:20:39 <jmikola|w>	lsmith: so the wrapper is just to explicitly define deps, but also ensure that you don't run into cyclic dependencies?
Dec 09 11:20:53 <lsmith>	jmikola|w: its there to solve 2 issues
Dec 09 11:20:58 <lsmith>	1) explicitly define dependencies
Dec 09 11:21:15 <jmikola|w>	and lazy loading?
Dec 09 11:21:22 <lsmith>	2) make it possible to use different services for the same get($foo) used in different controllers
Dec 09 11:21:25 <jmikola|w>	for something like switf mailer?
Dec 09 11:21:34 <lsmith>	and it obviously retains all the original features of the container
Dec 09 11:21:38 <lsmith>	aka lazy loading dependencies
Dec 09 11:21:55 <henrikbjorn>	what about a service wrapper instead of wrapping the container?
Dec 09 11:21:57 <fabpot>	if you want different mailer, just define several services: mailer.foo, mailer.bar, ...
Dec 09 11:22:00 <lsmith>	if you look at the above linked post
Dec 09 11:22:14 <lsmith>	fabpot: yes .. but this would need to be hardcoded into the controller
Dec 09 11:22:17 <jmikola|w>	i find (2) a bit unsettling... using one name for different things in places... i thought that's what aliases are for
Dec 09 11:22:27 *	vjousse (~vjousse@88-139-189-240.adslgp.cegetel.net) has joined #symfony-dev
Dec 09 11:22:28 <avalanche123>	if you have a dependencies that you never use, its a smell that you need to split your controller
Dec 09 11:22:31 <lsmith>	meaning you have to do repetitive code in all your controllers .. and it would make the dependencies even less clear
Dec 09 11:22:44 <lsmith>	as suddenly you not only have $this->container->get('foo')
Dec 09 11:22:47 <lsmith>	to scan for
Dec 09 11:22:52 <henrikbjorn>	lsmith: you can still overwrite the mailer service
Dec 09 11:22:55 <jmikola|w>	lsmith: i do see a need for lazy loading services, but i think that has to be done on a service-by-service basis
Dec 09 11:23:03 <lsmith>	but $this->container->get($foo); .. and then search for what $foo is
Dec 09 11:23:08 <fabpot>	jmikola|w: +1 for your two last comments
Dec 09 11:23:43 <fabpot>	overall, I'm strongly -1
Dec 09 11:23:49 <avalanche123>	me too
Dec 09 11:23:49 <lsmith>	avalanche123: i agree that optional dependencies are a smell ..
Dec 09 11:23:53 <henrikbjorn>	i think another issue is that we need to finde a best pratice for services in controllers
Dec 09 11:24:01 <lsmith>	so is it a best practice to forward emailing to another controller?
Dec 09 11:24:03 <henrikbjorn>	as being to explicit leads to boilerplate code
Dec 09 11:24:07 <henrikbjorn>	and duplication
Dec 09 11:24:19 <jmikola|w>	henrikbjorn: i tend to make getRequest, getSimplecas, getWhatever() methods in my controllers, with type-hints.. and they just return $this['whatever']
Dec 09 11:24:27 <fabpot>	lsmith: sending emails does not belong to controllers anyway
Dec 09 11:24:43 <jmikola|w>	so within my controller, it's very clear what I use, and I avoid referring to the container directly in my action method bodies
Dec 09 11:24:45 <henrikbjorn>	jmikola|w thats a good idea with a base controller for request etc?
Dec 09 11:24:46 <avalanche123>	best practice is only to inject what you need
Dec 09 11:25:05 <jmikola|w>	it would also port over nicely if you turned your controller into a service and injected those same deps
Dec 09 11:25:06 <henrikbjorn>	avalanche123: but most of the time you need the exact same things
Dec 09 11:25:12 <lsmith>	fabpot: well thats fine .. but if you need to inject a helper that does the email sending .. then you still have a dependency on swift mailer in your controller .. that you will rarely need
Dec 09 11:25:14 <henrikbjorn>	like templating, request, security
Dec 09 11:25:15 <jmikola|w>	the getter bodies would change, but your real action code wouldn't
Dec 09 11:25:17 <avalanche123>	henrikbjorn ?
Dec 09 11:25:29 <avalanche123>	henrikbjorn, if not in all actions - split
Dec 09 11:25:30 <jmikola|w>	henrikbjorn: avalanche123 made interface-aware injection, so this would eliminate lots of common code
Dec 09 11:25:41 <lsmith>	avalanche123: again .. so how do you handle a controller for users .. where one of the many actions is user registration
Dec 09 11:25:48 <jmikola|w>	if your controller was RequestAware and SecurityAware, etc.  you could automatically inject those services
Dec 09 11:25:50 <lsmith>	is user registration then its own controller?
Dec 09 11:25:53 <henrikbjorn>	yes but im not a fan of specifing my controllers as service :)
Dec 09 11:26:43 <lsmith>	jmikola|w: interface injection fails miserably imho
Dec 09 11:27:17 <lsmith>	i think its not acceptable to hardcode that everything depending on one interface or container get key to be the same for all services
Dec 09 11:27:25 <jmikola|w>	lsmith: avalanche123 just suggested (in person) something like what doctrine does, generating proxy classes for things
Dec 09 11:27:31 <lsmith>	thats taking most of the power out of DI
Dec 09 11:27:31 <jmikola|w>	we could automatically lazy-load services
Dec 09 11:27:58 <lsmith>	you need to be able to inject a different mailer, a different templating etc into a service from the outside
Dec 09 11:27:59 <avalanche123>	lsmith, I'm not following
Dec 09 11:28:02 <jmikola|w>	but this would certainly be an opt-in behavior - i think it'd be a bit much to do for everyone by default
Dec 09 11:28:20 <avalanche123>	lsmith, aliases are your friends
Dec 09 11:28:28 <lsmith>	aliases are global
Dec 09 11:28:30 <jmikola|w>	lsmith: if each of your various mailers has unique service id's, why not use those are create aliases as you like
Dec 09 11:28:39 <henrikbjorn>	sounds like the dic is becommng the new sfContext and where everything should be defined
Dec 09 11:28:41 <henrikbjorn>	which is bad
Dec 09 11:28:42 <henrikbjorn>	imo
Dec 09 11:28:47 <fabpot>	wow, that's a lot of discussion. Inject the container, and be done with it. It solves all your problems.
Dec 09 11:28:55 <avalanche123>	haha:)
Dec 09 11:29:02 <lsmith>	i have controller A) that i want to inject swift mailer .. and controller B) that i want to inject foo mailer
Dec 09 11:29:13 <lsmith>	fabpot: it doesnt
Dec 09 11:29:24 <lsmith>	and i want this to be done from the outside
Dec 09 11:29:35 <lsmith>	injecting the container, interface injection both fail here
Dec 09 11:29:35 <avalanche123>	lsmith - don't use interface injection for that:)
Dec 09 11:29:37 <henrikbjorn>	lsmith: that isnt a problem define two mailer services and inject the one you need?
Dec 09 11:29:52 <henrikbjorn>	you dont typehint them anyway :)
Dec 09 11:30:04 <lsmith>	henrikbjorn: type hinting is for interfaces
Dec 09 11:30:08 <lsmith>	anyway .. timebox is over
Dec 09 11:30:23 <avalanche123>	anyway - I'm -1 on the wrapper
Dec 09 11:30:38 <everzet>	+1 on "-1" =)
Dec 09 11:30:44 <avalanche123>	http://engineering.shopopensky.com/post/inheritance-in-php-or-why-you-want-to-use-an-interface-or-an-abstract-class
Dec 09 11:30:48 <lsmith>	yeah .. it seems most people are fine with a severely limited DI in Symfony2
Dec 09 11:30:51 <jmikola|w>	-1 for self-promotion
Dec 09 11:31:03 <lsmith>	ok next topic
Dec 09 11:31:17 <lsmith>	johanness is still not here it seems
Dec 09 11:31:24 <lsmith>	More flexible password encoding: http://bit.ly/hv7pfK
Dec 09 11:31:52 <lsmith>	this pull request spawned from a discussion between ornicar, johanness and myself in here
Dec 09 11:32:10 <jmikola|w>	lsmith: i assume a password encoding service was suggested?
Dec 09 11:32:25 <lsmith>	i think there are two issues
Dec 09 11:32:36 <lsmith>	1) johanness wants more flexibility in the hashing
Dec 09 11:32:54 <lsmith>	specifially hardcoding the algorithm in the provider will be too limiting in many cases
Dec 09 11:33:09 <jmikola|w>	is the algorithm stored in the account object, as is done in sfGuard?
Dec 09 11:33:15 <lsmith>	for example you change the hashing for new users, but want to support the old hashing until users have confirmed their password
Dec 09 11:33:32 <lsmith>	jmikola|w: no .. its hardcoded in provider configuration
Dec 09 11:33:39 <henrikbjorn>	add a getPasswordEncoder in the account interface ?
Dec 09 11:34:07 <jmikola|w>	lsmith: I'd be in favor of storing the algo; something from http://us3.php.net/hash_algos
Dec 09 11:34:11 <lsmith>	2) another problem is that currently the user account object is responsibile for hashing the password on creation, while the security firewall is responsible for hashing when authenticating
Dec 09 11:34:11 <everzet>	i think i love variant #1 https://github.com/fabpot/symfony/pull/250#issuecomment-596394
Dec 09 11:34:17 <jmikola|w>	that would make the hash implemention very portable
Dec 09 11:34:22 *	old_sound_ (~mrhyde@61.170.133.210) has joined #symfony-dev
Dec 09 11:34:35 *	old_sound_ has quit (Remote host closed the connection)
Dec 09 11:34:54 <jmikola|w>	a number of other projects (outside of symfony) store the hash algo on the user object; i see nothing wrong with that
Dec 09 11:35:04 <lsmith>	jmikola|w: right
Dec 09 11:35:04 <jmikola|w>	very ideal for backwards compatibility
Dec 09 11:35:13 <henrikbjorn>	whats wrong with having the user object returning the right encoder?
Dec 09 11:35:25 *	old_sound_ (~mrhyde@222.44.41.33) has joined #symfony-dev
Dec 09 11:35:28 <henrikbjorn>	if we just return the algorithm we still dont know what encoder have been used
Dec 09 11:35:29 <lsmith>	henrikbjorn: basically the question is who should be responsible for what
Dec 09 11:35:38 <jmikola|w>	and the hash_algos() and hash() call is probably 3 or 4 LOC, not a concern if duplicated between the firewall and the account itself
Dec 09 11:35:50 <lsmith>	should the user account object ask the security firewall to hash passwords for creation
Dec 09 11:35:59 <jmikola|w>	we do this at OpenSky, although a Java CAS server is doing the firewall bit now :)
Dec 09 11:36:02 <mvrhov>	lsmith, I've always put the verfy pwd to user model
Dec 09 11:36:07 <lsmith>	or should the firewall ask the user account object to hash the password on authentication
Dec 09 11:36:20 <jmikola|w>	lsmith: imo no, you should be able to create a user account (with password) completely independently
Dec 09 11:36:41 <jmikola|w>	if anything, you'd want a central place to store what hash algo should be used by default for new users
Dec 09 11:36:59 <lsmith>	jmikola|w: i also agree .. to me the hashing should be handled by the user account object
Dec 09 11:37:02 <jmikola|w>	and perhaps blacklist outdated hash algos from even being allowed to authenticate
Dec 09 11:37:06 <lsmith>	for both creation and authentication
Dec 09 11:37:25 <jmikola|w>	you might want to let someone log in with an md5 hashed password, but requested they re-set their pw so you can use sha256, etc
Dec 09 11:37:25 <lsmith>	fabpot: do you have thoughts on this?
Dec 09 11:37:43 *	old_sound has quit (Ping timeout: 250 seconds)
Dec 09 11:37:44 *	old_sound_ is now known as old_sound
Dec 09 11:38:43 <lsmith>	anyone else have opinions?
Dec 09 11:38:49 <lsmith>	otherwise i guess we move on to the next topic
Dec 09 11:39:18 <lsmith>	going once ..
Dec 09 11:39:24 <avalanche123>	move on:)
Dec 09 11:39:26 <lsmith>	twice
Dec 09 11:39:27 <lsmith>	Eager Response Creation Options: http://bit.ly/eRxDa7
Dec 09 11:39:39 <lsmith>	avalanche123: johanness isnt here
Dec 09 11:39:47 <lsmith>	you also wanted to discuss this topic
Dec 09 11:39:55 <lsmith>	can you explain things briefly?
Dec 09 11:40:20 <avalanche123>	I dunno:)
Dec 09 11:40:24 <lsmith>	k
Dec 09 11:40:27 <avalanche123>	I was hoping to get explanations
Dec 09 11:40:29 <lsmith>	i will do my best then
Dec 09 11:40:51 <avalanche123>	thx
Dec 09 11:40:52 <lsmith>	johanness suggested that there should be some way for listeners to mess with the response object
Dec 09 11:41:16 <lsmith>	however right now the response is obviously created much later
Dec 09 11:41:23 <lsmith>	more importantly its non shared
Dec 09 11:41:44 <lsmith>	so a controller that has a response inject will get a different instance
Dec 09 11:41:54 <lsmith>	than whatever one might be messing with in a listener earlier in the request
Dec 09 11:42:16 <lsmith>	so he was exploring ways of how to make sort of a "master response"
Dec 09 11:42:27 <lsmith>	or a 1:1 relation between requests and responses
Dec 09 11:42:37 <lsmith>	to enable listeners to mess with the reponse .. before controllers
Dec 09 11:42:57 <johanness>	sorry, i'm a bit late, the idea for the eager response is that you always have a response available for each request which you can modify at every point during the processing of each request
Dec 09 11:42:57 <lsmith>	i think however so far no really desireable solution has been found
Dec 09 11:43:22 <johanness>	right now the response is always created in the controller/view
Dec 09 11:43:34 <johanness>	but i think performance wise it indifferent when we create the response
Dec 09 11:43:44 <johanness>	and we always need a response, so we can create it earlier
Dec 09 11:43:54 *	mapi_ (~mapi2EE@dslb-092-073-142-137.pools.arcor-ip.net) has joined #symfony-dev
Dec 09 11:44:04 <johanness>	this makes sense if you for example need to set cookies/headers from a listener
Dec 09 11:44:26 <jmikola|w>	johanness: i'm just discussing with kriswallsmith the idea of kernel being the request/response container
Dec 09 11:44:29 <jmikola|w>	and thusly a response factory
Dec 09 11:44:32 <jmikola|w>	instead of DIC
Dec 09 11:44:44 <lsmith>	johanness: lets assume we dont do this .. it effectively means one would have to write the things to set on the reponse "somewhere"
Dec 09 11:44:45 <jmikola|w>	so the moment a request is handled, the response could be created and available for that master/sub request
Dec 09 11:44:46 <jmikola|w>	thoughts?
Dec 09 11:45:01 <lsmith>	so that the controller/view then does whatever the listener needs set on the response
Dec 09 11:45:06 <johanness>	jmikola|w: that's the idea
Dec 09 11:45:26 <johanness>	i think kernel would be good since we cannot really have it on the container
Dec 09 11:45:32 <lsmith>	which is obviously cludgy and lots of code to write
Dec 09 11:45:49 <lsmith>	johanness: so just like we have a master request
Dec 09 11:45:58 <lsmith>	we would have an accompanying master response?
Dec 09 11:46:08 <johanness>	lsmith: right now, i'm queueing the changes in a property and apply them on core.response
Dec 09 11:46:13 <lsmith>	obviously if one decides to return a totally new response
Dec 09 11:46:13 <johanness>	which seems just not right
Dec 09 11:46:20 <lsmith>	one could grab stuff from the master response
Dec 09 11:46:43 <lsmith>	aka .. one would still be free to not return the "master" response in a controller
Dec 09 11:46:51 <jmikola|w>	johanness: using factory-method's we can indeed still make it a service, and allow it to be fetched from the kernel
Dec 09 11:46:57 <fabpot>	I really like the possibility to just "return new Response();"
Dec 09 11:47:25 <johanness>	jmikola|w: but if it gets injected into a service, how would be re-inject it for a sub-request?
Dec 09 11:47:44 <jmikola|w>	response should not be shared, so it would invoke the factory-method each time it is injected
Dec 09 11:48:00 <jmikola|w>	the same way DIC makes "new Response()" for the current response service definition
Dec 09 11:48:29 <kriswallsmith>	i'm don't think the kernel should be a response factory
Dec 09 11:48:39 <kriswallsmith>	if we want eager response, just inject it into handle()
Dec 09 11:48:42 <jmikola|w>	fabpot: i suppose it's unsettling to deal with a response well before a controller has even been invoked, such as during a request listener
Dec 09 11:48:44 <johanness>	jmikola|w: hm, and how could i access the response which belongs to the current request?
Dec 09 11:48:55 <jmikola|w>	although i see why you'd want to for some cases
Dec 09 11:48:59 <kriswallsmith>	that's what i do in buzz
Dec 09 11:49:14 <jmikola|w>	^^ johanness perhaps take a look at that before we revisit this topic
Dec 09 11:49:31 <fabpot>	jmikola|w: I think responses should only be created just after the controller has been defined, not before
Dec 09 11:49:56 <everzet>	fabpot: +1 on this
Dec 09 11:50:09 <lsmith>	fabpot: so you prefer that listeners place what they need set in the response somewhere and then having the controller apply those things?
Dec 09 11:50:38 <fabpot>	lsmith: I don't see why you would like to store something for the response so early in the process
Dec 09 11:50:40 <jmikola|w>	lsmith: or a core.controller listener
Dec 09 11:50:49 <johanness>	fabpot: see the remembermelistener
Dec 09 11:50:57 <jmikola|w>	oops, core.view rather
Dec 09 11:50:58 <lsmith>	johanness was just going to say the same thing
Dec 09 11:50:59 <johanness>	it checks the cookie, if it's invalid it needs to unset it
Dec 09 11:51:08 <jmikola|w>	core.controller is before the controller is invoked
Dec 09 11:51:23 <johanness>	it checks the cookie on core.security, and unsets it on core.response
Dec 09 11:51:55 <jmikola|w>	johanness: what's the problem with using core.response to modify the response?
Dec 09 11:52:06 <everzet>	johanness: why not redirect/follow to logoff?
Dec 09 11:52:45 <johanness>	everzet: because an invalid, possibly expired cookie should not distrub the user, he is not even logged in yet :)
Dec 09 11:53:14 <johanness>	jmikola|w: that's possible, but you'll have to check the cookie on core.security, you can't delay that until core.response
Dec 09 11:53:15 <lsmith>	ok .. getting to the end of the timebox
Dec 09 11:53:23 <lsmith>	there was another topic Removal of the generic field block in form.twig: http://bit.ly/hcO6bK
Dec 09 11:53:24 <everzet>	johanness: got it =)
Dec 09 11:53:29 <lsmith>	bernhard isnt here .. and he never commented
Dec 09 11:53:33 *	meze (~kvirc@2001:0:5ef5:79fd:c04:399:c1b1:dabd) has joined #symfony-dev
Dec 09 11:53:35 <johanness>	then you'll need to carry that state over to core.response which is not so optimal i think
Dec 09 11:54:05 <lsmith>	the main issue there is that for a full form field_group in form.twig is not always useful
Dec 09 11:54:23 <lsmith>	because you cannot inject anything into the field group form the template (like a submit button)
Dec 09 11:54:26 <fabpot>	johanness: I don't think this is really a problem, especially if both listeners are in the same class
Dec 09 11:54:44 <lsmith>	so if you want to wrap all fields into some html code .. you know have to override each field type separately
Dec 09 11:54:44 <johanness>	fabpot: what if there are sub-requests? :)
Dec 09 11:54:58 <lsmith>	because there isnt a field block anymore which is applied to all field types
Dec 09 11:55:11 <fabpot>	you can check that you are doing your business only for the main request
Dec 09 11:55:28 <jmikola|w>	lsmith: did the field block used to render a field with its label?
Dec 09 11:55:35 <lsmith>	jmikola|w: yes
Dec 09 11:55:35 <jmikola|w>	i'm sadly not familiar with the twig templates for forms
Dec 09 11:55:59 <henrikbjorn>	lsmith: have u gotten it to wokr by having it rendering a whole field incl errors and labels?
Dec 09 11:56:01 <jmikola|w>	i'd agree that we probably want something like that... that's how admin generator in sf1 worked, so you can decide to use tables or lists for form display
Dec 09 11:56:36 *	Garfield-fr has quit (Quit:  ⏏)
Dec 09 11:57:01 <jmikola|w>	lsmith: perhaps this was an incomplete change or oversight (removal of the field block)
Dec 09 11:57:09 <lsmith>	https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/TwigBundle/Resources/views/form.twig
Dec 09 11:57:22 <lsmith>	as you can see in field_group
Dec 09 11:57:23 <jmikola|w>	otherwise, maybe bernhard expects you to override the form block yourself and create your own field block if desired
Dec 09 11:57:42 <lsmith>	the rendering of the label, errors and the widget itself are done individually
Dec 09 11:57:50 <jmikola|w>	so a field block would let you customize the contents of <div/>
Dec 09 11:57:59 <lsmith>	what i want is a field block that handles putting together the label/error/widget
Dec 09 11:58:05 <jmikola|w>	i definitely think the order of label/errors/field shouldn't be hard-coded like this
Dec 09 11:58:33 <lsmith>	jmikola|w: of course you can override the field_group quite easily
Dec 09 11:58:36 <lsmith>	however
Dec 09 11:58:48 <jmikola|w>	that duplicates more code than you need to change :)
Dec 09 11:58:54 <lsmith>	lets say you want to use <li> instead of <div> .. then you cannot use the field_group for rendering
Dec 09 11:59:18 <jmikola|w>	lsmith: if you wanted to use a table or <li>, you'd probably have to change field_group too
Dec 09 11:59:19 <lsmith>	and instead you need to override all *_field blocks
Dec 09 11:59:34 <lsmith>	jmikola|w: you simply cannot use field_group at all!
Dec 09 11:59:46 <lsmith>	because you cannot add a submit button from inside the template
Dec 09 11:59:57 <lsmith>	it would mean you would have to add the submit button in the form class itself
Dec 09 12:00:00 <lsmith>	which is a big nono
Dec 09 12:00:22 <jmikola|w>	wouldn't you add the submit between the <form> {{ field_group }} </form> in your outside template?
Dec 09 12:00:29 <jmikola|w>	i assume field_group doesn't render the form itself
Dec 09 12:00:39 <jmikola|w>	just its inner fields (or any group's inner fields)
Dec 09 12:01:07 <henrikbjorn>	jmikola|w: it dosent
Dec 09 12:01:08 <lsmith>	but with a list and table you need everything to be surrounded by a <ul> or <table>
Dec 09 12:01:16 <jmikola|w>	if you're using tables, field_group would start and end with the ul/table tag
Dec 09 12:01:26 <lsmith>	leaving those out you could make it work .. but that would mean the field group would render broken html
Dec 09 12:01:38 <jmikola|w>	and i see the problem if you wanted a submit button injected within the ul or table
Dec 09 12:01:43 <lsmith>	aka multiple <li> without a <ul> which imho is ugly too
Dec 09 12:01:56 <lsmith>	anwyay .. time is up for today
Dec 09 12:02:05 <lsmith>	i guess i will try to hunt down bernhard ..
Dec 09 12:02:13 <lsmith>	everybody is invited to post on the thread on the list
Dec 09 12:02:18 <jmikola|w>	i'll grab the logs
Dec 09 12:02:30 <jmikola|w>	lsmith: i suggest linking to the places to follow up in each topic on the irc wiki notes
Dec 09 12:02:33 <lsmith>	http://groups.google.com/group/symfony-devs/browse_thread/thread/342579e9170d5a6a#
Dec 09 12:02:36 <jmikola|w>	since there are various convo's to continue
Dec 09 12:02:43 <lsmith>	jmikola|w: k