You must first sign up to be able to contribute.


Refresh user after unserializing

This topic was discussed "accidentally". This topic is about giving the provider a chance to refresh the user data after it was unserialized in a new request. Fabien said that he likes the patch Johannes wrote but still needs a bit of time to review all the changes in a branch he created for this

Addition of Remember Me capabilities

Currently the security firewall does not offer any hooks to do rememberme cookie handling. Again Johannes has written a patch for this, but its again a large merge and depends on the 252 pull. Due to the size Fabien again asked for more time to review the patch, but said it looks good in principle. Bulat asked "how would remember me work with rest apis" but it was agreed that its not relevant for REST API's

Service Container wrapper

Lukas proposed this as an alternative approach to adding wrappers around extensive services, which can be problematic for those injecting services explicitly when the service being injected is optional. The idea would be that most people that inject services explicitly do so because they want to have control over the exact services being injected. The wrapper would add a possibility to get tighter control over the dependencies while injecting the container and thereby no longer suffering from performance penalties for optional dependencies. However an overwhelming majority did not find this proposal feasible.

More flexible password encoding

Another Johannes patch Right now the security firewall offers a very tight interface that providers can implement (getPassword() and getSalt()) with the algorithm hardcoded. However this means that one authentication source may only use a single hashing algorithm. Furthermore the user account object needs to implement hashing for user creation on its own, requiring duplicate configuration and code. This patch explores various ways for either the user account object or the security firewall to rely on the other side for hashing to enable more flexibility. Jeremy disagree's favoring to keep things separated and simply rely on ext/hash on both sides. The topic did not conclude with a final decision.

Eager Response Creation Options

Another Johannes topic: "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". This is particularly relevant for listeners that act before the controller is created where usually the response is instantiated. However for example setting a RememberMe? cookie currently requires storing that cookie somewhere in the security context and then applying the changes in the "core.response" listener. Jeremy mentioned that he is currently discussing with Kris the "idea of kernel being the request/response container" aka using factory methods in the Kernel rather than the DIC to make instances of these services. Fabien interjected that he "really like the possibility to just "return new Response();"". And there was agreement about the fact that it seems wrong to create the Response before the Controller. The topic did not conclude with a final decision.

Removal of the generic field block in form.twig

During the last refactoring of form.twig the generic "field" block was removed in favor of just a "field_group" which handles the rendering of the errors/labels/widget and specialized field blocks for every widget type. This means adding some formatting to just fields isn't possible anymore and using the "field_group" is often not feasible when using lists or tables for example, since there is no sensible way to injecting submit buttons or table headers in that case. Since Bernhard wasn't at the meeting Lukas said he would raise the issue with him once more to get a resolution.

IRC logs

Dec 09 11:03:10 <lsmith>	so i guess lets start with Service Container wrapper:
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:
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>
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
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 ( 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
Dec 09 11:16:39 *	wissl ( 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 ( 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
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>
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:,, ...
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 ( 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>
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:
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
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
Dec 09 11:34:17 <jmikola|w>	that would make the hash implemention very portable
Dec 09 11:34:22 *	old_sound_ (~mrhyde@ 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@ 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:
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_ ( 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, 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, 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:
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>
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>
Dec 09 12:02:36 <jmikola|w>	since there are various convo's to continue
Dec 09 12:02:43 <lsmith>	jmikola|w: k