You must first sign up to be able to contribute.


Console dependency injection

The proposal is to turn the CLI commands into services. The main concern is that this will add yet even more services to the dumped DIC php class which would be loaded when rendering web pages. It was decided that at this point its not even clear at what size this will really become an issue. More importantly any such issues should be mitigated by keeping the CLI command services separate from the rest. This way they could be kept out of the DIC when rendering web pages: "We can also have a AppKernel? and a AppCliKernel? that extends AppKernel? and just override the container configuration" (volunteers needed

Best practices for dynamic service definitions

"The issue here is that for example in DoctrineBundle? we have dynamic services and right now these services are essentially hardcoded in the extension class." We quickly agreed to take an approach first used by the security component which defines template services which can be tweaked by the end user in the normal way, which then get copied and dynamically adapted by the given bundle. Most of the discussion then revolved about how to clean these template services so that they do not end up in the dumped DIC and how such template services should be identified. The tentative agreement was to "tag" them as templates in the service definition. Furthermore removing these services should either be done in the Extension base class or in the DIC dumper itself (volunteers needed

Security context serialization between requests

The issue here is the question of how to prevent stale users as data about users is "cached" in the session. More over the problem of choosing the right provider to reload the user. As a first step it was agreed to require and store a unique of the name of the provider to ensure that the right provider is chosen when unserializing (Thibault volunteered to take a look at There are still open concerns here, like what happens with active sessions if the provider name is ever changed. Also there is still a need to implement different strategies to update the "cached" data in the session: on change, on very request, at certain intervals, on the next request after a change etc. Finally the "issue about sharing the security context remains, right now it is shared".

Current status and roadmap of the form framework and the admin generator

Bernhard stated that "the roadmap is to finish the form and Validator by the end of the year". The admin generator will come after that, potentially in cooperation with the Symfony CMF team. It will be a bundle and its not yet clear if it will be part of the core, though several people said that they think its very important to have it be part of core. Bernhard said it would be helpful if people would help verify the open bug reports (volunteers needed The next big task aside from fixing bugs is thinking about how JS integration into form elements should work. In a little side node Jordi asked Fabien what the next big things are for Symfony2 core and Fabien said that the main thing to do now is to fix bugs. Fabien also mentioned that he has some unfinished code for handling ACL's that he would be willing to share with interested people.

IRC logs

Nov 18 10:58:48 <lsmith>	ok .. i closed the vote
Nov 18 10:59:00 <lsmith>	avalanche123: sure lets go
Nov 18 10:59:08 <avalanche123>	hi everyone!
Nov 18 10:59:19 <avalanche123>	the first topic on the list is the console DIC
Nov 18 10:59:26 <avalanche123>	or rather I think it makes sense
Nov 18 10:59:37 <avalanche123>	to register all console commands as services in DIC
Nov 18 10:59:43 <avalanche123>	for easy testing and mocking
Nov 18 10:59:47 <avalanche123>	more here -
Nov 18 11:00:09 <avalanche123>	the post there includes an example  of rewriting the existing command
Nov 18 11:00:17 <avalanche123>	in DIC compatible way
Nov 18 11:00:23 <avalanche123>	and making it testable
Nov 18 11:00:46 <lsmith>	there is a pull request too
Nov 18 11:00:55 <avalanche123>	lsmith is correct
Nov 18 11:01:11 <avalanche123>	there is a pull request, but it doesn't include the rewriting of existing commands
Nov 18 11:01:23 <lsmith>	i guess the main concern against adding this is that it will add yet more services that will be cached in the DIC class
Nov 18 11:01:31 *	Garfield-fr has quit (Quit:  ⏏)
Nov 18 11:01:41 <avalanche123>	yes, fabpot said, that that would make the container much bigger
Nov 18 11:01:42 <lsmith>	which is a growing concern even before adding this
Nov 18 11:02:00 <lsmith>	are there any other concerns?
Nov 18 11:02:25 <avalanche123>	and I agree, that it would, however, OpenSky's largest DIC is 201,327 bytes
Nov 18 11:02:31 <avalanche123>	which doesn't seem that big
Nov 18 11:02:36 <avalanche123>	and we ahve lots of stuff there too
Nov 18 11:02:40 <avalanche123>	*have
Nov 18 11:03:06 <avalanche123>	so maybe we should in a feature branch convert all commands to services and see how much bigger the container gets?...
Nov 18 11:03:07 <lsmith>	right .. but opensky has taken the "multiple app" approach .. which might be the best practice to handle this concern
Nov 18 11:03:15 <avalanche123>	true
Nov 18 11:03:18 <fabpot>	another concern is that you will "load" these service definitions when calling your app from the web, where you will never have a need for them
Nov 18 11:03:39 <avalanche123>	yes, I agree, that its sub-optimal
Nov 18 11:03:53 *	bschussek (~bschussek@ has joined #symfony-dev
Nov 18 11:03:56 <avalanche123>	I was thinking about how to split container for quite a bit
Nov 18 11:04:04 <lsmith>	right .. if we were to keep a separate DIC with all the CLI services, that falls back to the web DIC in case a missing service is called, then this would "fix" that concern
Nov 18 11:04:10 <fabpot>	also, commands are like controllers, they hardly need to be tested, as the meat of the command should be in the model
Nov 18 11:04:20 <fabpot>	also because then, it can be resued in another context
Nov 18 11:04:21 <lsmith>	but it would mean that the services need to be managed in separate configs
Nov 18 11:05:11 <lsmith>	well testability is also not my main concern here .. but extensibility .. though i have not yet tried to extend/modify a CLI command
Nov 18 11:05:11 <avalanche123>	I see
Nov 18 11:05:32 <avalanche123>	doctrine commands for example could benefit from that
Nov 18 11:05:39 <fabpot>	lsmith: what do you want to "extend"?
Nov 18 11:05:51 <avalanche123>	since there would not be a need for bundle specific command classes that extend the base ones anymore
Nov 18 11:05:58 <fabpot>	avalanche123: you mean, refactoring code to a "model"
Nov 18 11:06:11 <avalanche123>	not sure
Nov 18 11:06:14 <avalanche123>	what I mean is
Nov 18 11:06:26 <avalanche123>	DIC gives you the benefit of configuration
Nov 18 11:06:33 <avalanche123>	which is not available with convention based
Nov 18 11:06:38 <avalanche123>	command instantiation
Nov 18 11:07:00 <avalanche123>	so doctrine for example needs to create these dummy command classes in their bundles
Nov 18 11:07:13 <avalanche123>	just because there is no way to point to the real ones
Nov 18 11:07:39 <avalanche123>	am I making sense?
Nov 18 11:07:44 <lsmith>	fabpot: for example you might take issue with how doctrine does DDL changes and you want to ensure that when doing DDL .. its using a different username .. a bit contrived but an example of where you might want to "extend" a core CLI command
Nov 18 11:07:45 <fabpot>	avalanche123: not sure ;)
Nov 18 11:07:49 <avalanche123>	:)
Nov 18 11:07:54 <jwage>	why is the size of the DIC problem? I mean of course you have a point where the size can cause problems but I think the point where the size is a problem is not realistically going to happen
Nov 18 11:08:16 <jwage>	has anyone tested or done any benchmarks or anything with a massive DIC?
Nov 18 11:08:24 <avalanche123>	jwage, I think we need to
Nov 18 11:08:32 <avalanche123>	otherwise its just an empty argument
Nov 18 11:08:38 <jwage>	I just can't imagine that it really is a problem
Nov 18 11:08:49 <fabpot>	lsmith: but a command is just a way to give your model some input and output something, nothing more
Nov 18 11:08:54 <avalanche123>	OpenSky's DIC is 4500+ loc
Nov 18 11:08:59 <jwage>	i think you;d have to have like thousands and thousands of services
Nov 18 11:09:01 <fabpot>	jwage: more code == less speed with PHP
Nov 18 11:09:03 <lsmith>	but isnt keeping the service configs separate with a "chained" DIC in CLI mode a pretty simple way to solve the issue if necessary
Nov 18 11:09:03 <jwage>	which is unrealistic
Nov 18 11:09:28 <jwage>	fabpot: i know, technically that is right, but the size to speed loss is so small i bet
Nov 18 11:09:28 <avalanche123>	lsmith, I think I agree
Nov 18 11:09:33 <jwage>	with the size of DIC we're dealing with
Nov 18 11:09:38 *	cliassom ( has joined #symfony-dev
Nov 18 11:09:56 <avalanche123>	so maybe we fix the size problem when it really becomes a problem?
Nov 18 11:09:57 <fabpot>	jwage: it's not (and I did some benchmark some months ago)
Nov 18 11:10:06 <jwage>	ok
Nov 18 11:10:09 <fabpot>	avalanche123: my point is not just about the size
Nov 18 11:10:18 <jwage>	so in opensky then since we have multiple apps this keeps the number of services low
Nov 18 11:10:20 <fabpot>	it's also about "polluting" the web DIC with non-web services
Nov 18 11:10:20 <lsmith>	avalanche123: thats my thinking .. i dont really see that the size issue will put us into a corner we cannot fix
Nov 18 11:10:22 <jwage>	b/c we only enable what that app needs
Nov 18 11:10:26 <jmikola|w>	sorry for the late comment (just returned to desk) - i think the issue of loading console commands in http-only apps is an issue, perhaps solved by a configuration option in symfony to control the loading of things
Nov 18 11:10:31 <jwage>	instead of having everything in one app and everything always enabled
Nov 18 11:10:35 *	cliassom ( has left #symfony-dev
Nov 18 11:10:47 <jmikola|w>	if console commands were tagged in DIC, an option could be employed to decide if you wanted to register all tagged console commands
Nov 18 11:10:53 <bschussek>	fabpot: what about having separate DICs for web and CLI?
Nov 18 11:10:57 <avalanche123>	but you might want to run command from an http app
Nov 18 11:11:06 <avalanche123>	say you have a message queue
Nov 18 11:11:08 <avalanche123>	rabbit
Nov 18 11:11:12 <fabpot>	avalanche123: NO
Nov 18 11:11:17 <avalanche123>	:)
Nov 18 11:11:21 <avalanche123>	ok, point taken
Nov 18 11:11:27 <fabpot>	avalanche123: you would probably reuse the code from your model, not the command itself
Nov 18 11:11:31 <lsmith>	btw .. 4 more minutes in the timebox
Nov 18 11:11:33 <jmikola|w>	or a shared service :)
Nov 18 11:11:57 <avalanche123>	yeah, I concur that is more semantically correct
Nov 18 11:12:04 <fabpot>	bschussek: probably possible
Nov 18 11:12:16 <fabpot>	bschussek: don't know how much complexity it would add though
Nov 18 11:12:23 <jmikola|w>	bschussek: wouldn't the be accomplished by just separate apps for web/cli?
Nov 18 11:12:23 <avalanche123>	still I'd like to test my commands, I don't see how that could be done without DIC
Nov 18 11:12:32 <jmikola|w>	or you wouldn't want to duplicate kernel code
Nov 18 11:12:34 <jwage>	fabpot: does spring have a console?
Nov 18 11:12:46 <lsmith>	well it means for one that the services for commands need to be specified in a separate file (i dont really think that tagging is the way to go)
Nov 18 11:12:57 <fabpot>	avalanche123: to make it clear, I'm not against introducing services for CLI commands
Nov 18 11:13:17 <jmikola|w>	fabpot: practically, the implementation is just loading things tagged as CLI commands, right?
Nov 18 11:13:24 <jmikola|w>	i haven't seen the pull request
Nov 18 11:13:27 <fabpot>	ok, I think I have a solution
Nov 18 11:13:50 *	avalanche123 held his breath
Nov 18 11:13:51 <jwage>	could we just have a cli version of the DI?
Nov 18 11:13:55 <fabpot>	as lsmith said, CLI commands are registered in another configuration file
Nov 18 11:14:01 <fabpot>	which is not loaded by the default Kernel
Nov 18 11:14:09 <fabpot>	but only when in console mode
Nov 18 11:14:48 <lsmith>	ok .. sounds like we have a task for someone to take over :)
Nov 18 11:14:54 <jmikola|w>	so this is an additional DI config, sharing the same application config?
Nov 18 11:15:20 <fabpot>	via another registerContainerConfiguration() method registerContainerCliConfiguration() for instance
Nov 18 11:15:22 <jmikola|w>	i assume CLI services would still want the main (i.e. web) di config
Nov 18 11:15:42 <lsmith>	ok .. seems to me like we made progress ..
Nov 18 11:15:48 <lsmith>	time to move to the next topic
Nov 18 11:15:55 <lsmith>	we have a bit of a 4 way tie here
Nov 18 11:15:58 <fabpot>	or we can also have a AppKernel and a AppCliKernel that extends AppKernel and just override the container configuration
Nov 18 11:16:09 <avalanche123>	fabpot I like it
Nov 18 11:16:09 <lsmith>	i propose we go to "Best practices for dynamic service definitions" next
Nov 18 11:16:27 <avalanche123>	lsmith, mind introducing the topic?
Nov 18 11:16:36 <pgodel_work>	I like the AppCliKernel idea
Nov 18 11:16:37 <lsmith>	so the issue here is that for example in DoctrineBundle we have dynamic services
Nov 18 11:16:52 <lsmith>	and right now these services are essentially hardcoded in the extension class
Nov 18 11:16:53 <jmikola|w>	lsmith: is this anything like the dynamic stuff inside security component too?
Nov 18 11:16:54 <jwage>	lsmith: i think we need services that are templates
Nov 18 11:16:56 <jwage>	tagged as templates
Nov 18 11:16:57 <fabpot>	lsmith: any conclusion before on the first topic?
Nov 18 11:17:02 <jwage>	and are never actually generated in the DIC
Nov 18 11:17:10 <jwage>	they are only used as a template to clone in the *Extension.php
Nov 18 11:17:21 <jwage>	so for example I can have a DI configuration for a Doctrine\DBAL\Connection
Nov 18 11:17:25 <fabpot>	jwage: that's what we have in the security extension
Nov 18 11:17:32 <jwage>	and it is used as the base for creating all connections in the *Extension.php
Nov 18 11:17:35 <fabpot>	I have a special security_template.xml config file with templates
Nov 18 11:17:44 <lsmith>	fabpot: my understanding is that we feel we can handle the issue of services for commands, by separating the CLI specific services
Nov 18 11:17:44 <jwage>	and we just load it in the *Extension.php ?
Nov 18 11:17:45 <fabpot>	and the services there are removed at the end of the configuration process
Nov 18 11:17:48 <jwage>	ah
Nov 18 11:17:49 <jwage>	ok
Nov 18 11:17:50 <fabpot>	so they don't end up in your container
Nov 18 11:17:50 <jwage>	hmm
Nov 18 11:17:54 <jwage>	couldn't we just add a tag?
Nov 18 11:18:04 <jwage>	and have it ignore the ones with that certain tag
Nov 18 11:18:11 <jmikola|w>	jwage:
Nov 18 11:18:36 <fabpot>	jwage: that can be a convention you have, sure
Nov 18 11:18:48 <jwage>	ya i just dont want each extension to have to manually remove them
Nov 18 11:18:51 <jwage>	and reimplement the same thing
Nov 18 11:18:56 <jwage>	over and over
Nov 18 11:19:26 <jmikola|w>	so adding some basic helper methods in Symfony\Component\DependencyInjection\Extension\Extension to handle this convention?
Nov 18 11:19:45 <jwage>	ya i dont want to have to do this
Nov 18 11:19:45 <jwage>
Nov 18 11:19:47 <jwage>	everytime
Nov 18 11:19:56 <jwage>	in the configuration i should be able to just tag a service is "template"
Nov 18 11:19:57 <jwage>	or something
Nov 18 11:19:58 <lsmith>	jwage: so we add a new attribute "template" ?
Nov 18 11:20:11 <fabpot>	jwage: sure
Nov 18 11:20:12 <jwage>	right, and then the builder won't generate those services
Nov 18 11:20:13 <Seldaek>	why not do this in the Container Dumper ?
Nov 18 11:20:13 <lsmith>	and those are never written in the phpDumper
Nov 18 11:20:20 <jwage>	Seldaek: thats what we're suggesting
Nov 18 11:20:26 <jwage>	instead of each extension having to reimplement the same removing code
Nov 18 11:20:36 <lsmith>	ok sounds like a plan
Nov 18 11:20:37 <Seldaek>	well, yeah, but suggestions sounded more like helper code in DI Extension
Nov 18 11:20:40 <fabpot>	jwage: no, we are suggesting to do that in the Extension, not in the Dumper
Nov 18 11:20:45 <jwage>	hmm
Nov 18 11:20:53 <Seldaek>	so I'd like to clarify the suggestion :)
Nov 18 11:21:06 <jmikola|w>	lsmith: would that possibly ruin the convention that loaders and dumpers won't change things?
Nov 18 11:21:08 <jwage>	this just seems weird
Nov 18 11:21:09 <jwage>
Nov 18 11:21:18 <jwage>	why not just get the tagged templates and remove them before dumping?
Nov 18 11:21:36 <lsmith>	hmm i guess because then you could indeed have a different behavior
Nov 18 11:21:44 <fabpot>	jmikola|w: exactly. Dumpers just, well, dump the container
Nov 18 11:21:49 <lsmith>	i guess atm in the first request it doesnt actually use the dumper
Nov 18 11:21:50 <jwage>	ok
Nov 18 11:22:00 <johanness>	you could also load the templates into a different container builder and clone them from there
Nov 18 11:22:01 <jmikola|w>	fabpot: does DIC generation just use phpdumper at the moment?
Nov 18 11:22:01 <avalanche123>	I think that is what will happen, just the "remove before dumping" takes place in Extension
Nov 18 11:22:07 <johanness>	instead of loading them into the actual container
Nov 18 11:22:33 <fabpot>	jwage: but I think it's fine to do that in the extensions as this is the only place where it makes sense to use templates, right?
Nov 18 11:22:46 *	maerlyn has quit (Quit: Leaving)
Nov 18 11:22:54 <fabpot>	lsmith: I don't know how many topics we have today, but I will need to leave in 30 minutes
Nov 18 11:22:56 <jwage>	yes i just worry that we leave it up to the developer to reimplement this removing everytime and it being inconsistent, or they don't do it
Nov 18 11:23:04 <jwage>	and they end up using templates and having the services in the DI
Nov 18 11:23:12 <fabpot>	jwage: no, we will provide a special tag and the method to remove them
Nov 18 11:23:15 <jwage>	ok
Nov 18 11:23:16 <lsmith>	fabpot: k
Nov 18 11:23:19 <jwage>	that works for me then
Nov 18 11:23:22 <Seldaek>	but why provide a method to remove them
Nov 18 11:23:27 <Seldaek>	why not just make it automatically
Nov 18 11:23:33 <Seldaek>	after calling the extensions
Nov 18 11:23:33 <jwage>	i just dont wanna have to to the $servicesToRemove = array(); foreach ($servicesToRemove
Nov 18 11:23:34 <jwage>	etc
Nov 18 11:23:34 <fabpot>	Seldaek: being explicit
Nov 18 11:23:42 <Seldaek>	well, it's explicitly tagged
Nov 18 11:23:55 <bschussek>	I agree with Seldaek
Nov 18 11:23:56 <jwage>	im not sure i see any reason not to remove it automatically
Nov 18 11:24:05 <jwage>	if its tagged as template, u dont want it as a real service
Nov 18 11:24:11 <Seldaek>	if you just call $this->removeTaggedServices(), and don't specify which you want to remove, it'll just remove all tagged templates for all extensions
Nov 18 11:24:15 <fabpot>	Seldaek: bschussek: jwage: I don't see where we will be able to do that automatically
Nov 18 11:24:29 <jmikola|w>	jwage: the logic for that shouldn't be in a dumper though
Nov 18 11:24:32 <Seldaek>	so either you do it all at the end, or you have to specify
Nov 18 11:24:34 *	wissl ( has joined #symfony-dev
Nov 18 11:24:39 <fabpot>	ok, I think we have a solution. Someone needs to work on an implementation now
Nov 18 11:24:48 <jwage>	i agree, if we have no way to do it properly then im ok with having to call the method explicitly
Nov 18 11:24:59 <lsmith>	yeah .. i think we have agreed on the principle
Nov 18 11:25:09 <avalanche123>	that could be implemented in the base Extension class
Nov 18 11:25:13 <lsmith>	the rest is detail .. which can still be discussed in the pull request
Nov 18 11:25:24 <Seldaek>	jwage: so the method is just a foreach that calls ->remove() on the array you give it? sounds a bit pointless to me but ok
Nov 18 11:25:25 <jwage>	could avalanche123 idea work?
Nov 18 11:25:34 <avalanche123>	at the end of load() method
Nov 18 11:26:01 *	ornicar ( has left #symfony-dev
Nov 18 11:26:05 *	ornicar ( has joined #symfony-dev
Nov 18 11:26:13 <lsmith>	so 5 more mins in this timebox .. or do we move on to the next topic?
Nov 18 11:26:15 <avalanche123>
Nov 18 11:26:29 <avalanche123>	right after the $method is called, n?
Nov 18 11:26:32 <avalanche123>	*no?
Nov 18 11:26:37 <bschussek>	as Fabien said, we have agreed on a principle. I suggest to move on
Nov 18 11:26:40 <lsmith>	ok
Nov 18 11:26:43 <fabpot>	lsmith: let's move to the next one

Nov 18 11:26:49 <lsmith>	to next topic .. ornicar plx .. security context serialization between requests:
Nov 18 11:27:07 <lsmith>	or johanness?
Nov 18 11:27:19 <ornicar>	so right now the user object is serialized
Nov 18 11:27:34 <ornicar>	to make it persistent
Nov 18 11:27:52 <ornicar>	when the user object is a doctrine entity or document
Nov 18 11:28:21 <ornicar>	it makes a problem, because the user object is unserialized and available from the token, but the doctrine entity/document manager is not aware of it
Nov 18 11:28:46 <ornicar>	I guess we have to find a way to make the object manager aware of it
Nov 18 11:28:47 <jmikola|w>	ornicar: are you suggesting we instead serialize the recipe to fetch it back from the provider? so at least the provider name and unique value from the user object?
Nov 18 11:29:18 *	johnkary ( has joined #symfony-dev
Nov 18 11:29:21 <ornicar>	yes, fetch it for each request sounds good to me
Nov 18 11:29:27 <jmikola|w>	is the actual managed entity/document serialized presently?
Nov 18 11:29:36 <avalanche123>	you could also just merge() it to manager
Nov 18 11:29:39 <johanness>	another thing is that right now the security context is shared among firewalls, if we decide to not-share it, the problem of reloading will become a bit easier
Nov 18 11:29:44 *	beberlei ( has joined #symfony-dev
Nov 18 11:29:50 <Seldaek>	what I do is: $this->em->merge($this->session->get('user'))
Nov 18 11:29:54 <beberlei>	sorry i am late :)
Nov 18 11:29:58 <jmikola|w>	avalanche123: you'd still need to know if it came from ORM or ODM provider, right?
Nov 18 11:30:04 <Seldaek>	but imo this should be done by hand whenever you want to actually change/persist the object
Nov 18 11:30:15 <ornicar>	you have to know what user provider to use
Nov 18 11:30:25 <Seldaek>	otherwise you force sql queries for nothing at every request, this is highly wasteful
Nov 18 11:30:26 <johanness>	spring allows to specify from which provider to load the user from specifically, but i don't really see this practically working with a shared security context
Nov 18 11:30:47 <beberlei>	is it really necessary to merge the user into the context every time?
Nov 18 11:30:54 <fabpot>	johanness: Spring is less flexible, so it is possible for them, not for us
Nov 18 11:30:55 <jmikola|w>	jwage/avalanche123 will merge()-ing back into ORM/ODM refresh it from the DB? otherwise we might get stale data in there
Nov 18 11:30:57 <ornicar>	Seldaek it's not only about modifying the user object. If you create a relation to the user object in another object, the manager needs to know the user object
Nov 18 11:31:00 <beberlei>	from a security pov i mean
Nov 18 11:31:02 <avalanche123>	jmikola|w, nope
Nov 18 11:31:12 <avalanche123>	it will add it to identity map AFAIK
Nov 18 11:31:16 <avalanche123>	maybe introduce event 'session.load'?
Nov 18 11:31:17 <Seldaek>	ornicar: yes well, that's what I mean. If you do any kind of write op, you should merge by hand
Nov 18 11:31:19 <jmikola|w>	so i'd be concerned about merging it and accidentally flushing old data
Nov 18 11:31:39 <johanness>	fabpot: yeah, what i said, it's not working for us :) but i also see a problem with sharing the security context
Nov 18 11:31:44 <Seldaek>	ornicar: there could be an automatic mode for people that don't want to care, but it also needs an advanced mode for performance
Nov 18 11:31:47 <avalanche123>	which could be overloaded from the Doctrine bundle?
Nov 18 11:32:00 <avalanche123>	to merge entities back to entity manager?
Nov 18 11:32:23 *	digitarald has quit (Ping timeout: 265 seconds)
Nov 18 11:32:36 <jmikola|w>	would this be a function of the provider class? if so, that's where EntityUserProvider is
Nov 18 11:33:02 *	digitarald ( has joined #symfony-dev
Nov 18 11:33:22 <johanness>	you would still need to know which use rprovider to use
Nov 18 11:33:28 <fabpot>	jmikola|w: the main problem is to know from which provider the user came from when he was authenticated
Nov 18 11:33:29 <jmikola|w>	perhaps we could use a designated event, such as security.user.provided
Nov 18 11:33:29 <johanness>	which isn't so trivial
Nov 18 11:33:36 <ornicar>	I think fetching the user for every request is better. If the user is modified, we want it to be applied to the token user
Nov 18 11:33:39 <jmikola|w>	which would receive the user object, whatever was serialized, and the provider code
Nov 18 11:33:43 <fabpot>	johanness: correct
Nov 18 11:33:58 <jmikola|w>	db-based providers could then refresh or merge as necessary
Nov 18 11:34:06 <ornicar>	we could save the provider name in the token?
Nov 18 11:34:30 <fabpot>	ornicar: probably possible, especially as they have names now IIRC
Nov 18 11:34:41 <lsmith>	ornicar: well thats an app design decision .. the data of the user is being cached in the session .. then you want to decide if on change you update all existing sessions
Nov 18 11:34:43 <jmikola|w>	ornicar: it would kind of suck if the provider name changed during deployment (people would get security sessions invalidated)
Nov 18 11:34:51 <lsmith>	just flag something in memcache to require a re-read
Nov 18 11:34:57 <lsmith>	or if you always just want to load again
Nov 18 11:35:28 <jmikola|w>	do apps allow multiple providers? or each firewall has one?
Nov 18 11:35:34 <ornicar>	yes
Nov 18 11:35:39 <johanness>	jmikola|w: multiple
Nov 18 11:35:44 <jmikola|w>	so if provider A doesn't find a user, we try provider B?
Nov 18 11:36:01 <ornicar>	I think each firewall has only one provider
Nov 18 11:36:02 <johanness>	thats dangerous, you risk logging in a different user
Nov 18 11:36:11 <fabpot>	ornicar: nope
Nov 18 11:36:44 <jmikola|w>	johanness: i agree it's a bit ambiguous, but that's probably a topic for next week, heh
Nov 18 11:37:04 <lsmith>	btw as fabpot and bschussek have to leave early .. i would like to move to "roadmap for form+admin gen" at 17:40 (CET) aka in 3 mins
Nov 18 11:37:09 <johanness>	requiring a unique name for the use rprovider and serializing it along with the token would be best, then we can pass all providers to the context listeners which chooses the right one
Nov 18 11:37:14 *	Skorney has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630])
Nov 18 11:37:18 <jmikola|w>	so barring the possibility of provider names changing, i think saving that name in the session is worth looking into
Nov 18 11:37:33 <fabpot>	jmikola|w: johanness: I agree
Nov 18 11:37:54 <jmikola|w>	and a flexible event that DoctrineBundle can use?
Nov 18 11:37:56 *	mvrhov ( has joined #symfony-dev
Nov 18 11:37:57 <ornicar>	I can work on that and submit a new pull request
Nov 18 11:38:48 <lsmith>	jmikola|w: provider names changing issues is then something for documentation i guess
Nov 18 11:39:03 <lsmith>	ok .. so moving to "form + admin gen roadmap" now?
Nov 18 11:39:09 <johanness>	still the other issue about sharing the security context remains, right now it is shared, and i'm not sure this is a good decision for complex configurations
Nov 18 11:39:09 <jmikola|w>	i'll follow up with ornicar on that over the week; sure
Nov 18 11:39:25 <ornicar>	ok
Nov 18 11:39:35 <lsmith>	johanness: lets get this worked out first
Nov 18 11:39:48 <lsmith>	bschussek: can you give us some information about the form roadmap
Nov 18 11:39:55 <lsmith>	and possibily also the admin generator?
Nov 18 11:40:14 <bschussek>	the roadmap is to finish the form and Validator by the end of the year
Nov 18 11:40:27 <bschussek>	I cannot work on the admin generator any sooner than that
Nov 18 11:40:43 <lsmith>	note we talked about the admin generator a bit in the context of the last CMF meeting:
Nov 18 11:40:57 <lsmith>	bschussek and jwage discussed some ideas there
Nov 18 11:41:09 <bschussek>	the idea was to share code with the CMF project, especially on the UI part
Nov 18 11:41:14 <lsmith>	bschussek: what are the main issues in the form/validation layer atm?
Nov 18 11:41:31 <lsmith>	anything you need help with? any major issues people should be aware of?
Nov 18 11:41:57 <bschussek>	there are a couple of fields and validators that need to be implemented
Nov 18 11:42:15 <lsmith>	looking at the open tickets:
Nov 18 11:42:22 <lsmith>	many seem to be related to form/validation
Nov 18 11:42:23 *	vjousse (~vjousse@ has joined #symfony-dev
Nov 18 11:42:29 <lsmith>	do you need help validating the tickets?
Nov 18 11:42:38 <bschussek>	lsmith: that would be great
Nov 18 11:42:38 <lsmith>	maybe some of them are no longer relevant?
Nov 18 11:42:40 *	digitarald has quit (Quit: digitarald)
Nov 18 11:42:44 <Seldaek>	bschussek: if you need help with simple stuff like that (implementing new validators..) feel free to shoot me a mail
Nov 18 11:42:45 <jmikola|w>	bschussek: for fields that might be coupled with JS (i'm thinking of CollectionField), is there any plan for packaging that with symfony? or perhaps the relevant JS would just belong in documentation as an example
Nov 18 11:42:46 <bschussek>	I did not have time to look through them yet
Nov 18 11:42:56 <bschussek>	Seldaek: ok
Nov 18 11:43:16 <bschussek>	jmikola|w: that's the next thing. Many fields are prepared for JS integration, but how we exactly do this needs to be worked out
Nov 18 11:43:36 *	vjousse has quit (Quit: Quitte)
Nov 18 11:43:54 <bschussek>	I think we don't need to discuss the JS integration here though, this needs better preparation
Nov 18 11:44:02 <Seldaek>	yeah having one-size-fits-all js is pretty much impossible
Nov 18 11:44:50 <Seldaek>	is the plan to ship Sf2 final with an admin generator?
Nov 18 11:44:55 <Seldaek>	or could that come later?
Nov 18 11:44:56 *	henrikbjorn has quit (Ping timeout: 245 seconds)
Nov 18 11:44:59 <lsmith>	one topic that we discussed on the list quite a bit is that the validation happens on the object state and not on the submitted data
Nov 18 11:45:07 <pgodel_work>	I would like to see it in sf2 final
Nov 18 11:45:10 <lsmith>	i guess you improved the documentation in this regard lately .. right?
Nov 18 11:45:14 <pgodel_work>	it is one of the biggest featues of symfony 1
Nov 18 11:45:24 <pgodel_work>	and selling points
Nov 18 11:45:28 <bschussek>	lsmith: I don't think this topic needs more discussion, just more documentation
Nov 18 11:45:32 <bschussek>	I haven't written that yet
Nov 18 11:45:36 <Seldaek>	also fabpot if you're here and got a minute to share the current state of things/what's coming next it'd be great
Nov 18 11:45:37 <lsmith>	k
Nov 18 11:45:46 <fabpot>	admin gen will be a bundle
Nov 18 11:45:48 <lsmith>	i also stumbled over the RepeatField:
Nov 18 11:45:53 <fabpot>	like everything else
Nov 18 11:46:02 <fabpot>	Seldaek: about what?
Nov 18 11:46:02 <lsmith>	there seems to be a conceptual issue there in relation to validation
Nov 18 11:46:09 <Seldaek>	fabpot: general Sf2 progress
Nov 18 11:46:15 <jmikola|w>	Seldaek: i think security was the last big surprise feature :)
Nov 18 11:46:25 <Seldaek>	fabpot: if you feel like sharing that is :)
Nov 18 11:46:33 <fabpot>	Seldaek: main features are finished (except perhaps Form/Validator)
Nov 18 11:46:34 <beberlei>	lsmith: i think having ext/filter (or an equivalent) do filtering on variables based on name / route might be an additional integration, but validation on the object is much better with regards to forms and validating business logic
Nov 18 11:46:38 <bschussek>	lsmith: I think that's a bug
Nov 18 11:46:42 <fabpot>	we need more testing now
Nov 18 11:47:00 *	mvrhov has quit (Read error: Connection reset by peer)
Nov 18 11:47:07 <Seldaek>	fabpot: ok fair enough :)
Nov 18 11:47:17 <fabpot>	and things like the admin gen is something we can do without any change to the core framework
Nov 18 11:47:23 <Seldaek>	I'll try to implement a caching kernel this weekend
Nov 18 11:47:26 *	mvrhov ( has joined #symfony-dev
Nov 18 11:47:30 <jmikola|w>	fabpot: would a continuous integration server on your fabpot branch be helpful? :)
Nov 18 11:47:30 <lsmith>	since the security component was committed .. i have seen a steady increase in pull requests .. but also increasingly shorter turn around time by fabpot in getting them in
Nov 18 11:47:32 <fabpot>	"caching kernel"?
Nov 18 11:47:33 *	henrikbjorn ( has joined #symfony-dev
Nov 18 11:47:35 <lsmith>	this is really great ..
Nov 18 11:47:47 <Seldaek>	fabpot: I mean.. the AppCache thingy, on top of the kernel, I'm tired sorry :)
Nov 18 11:47:50 <bschussek>	are there anymore questions on forms or validation?
Nov 18 11:48:00 <beberlei>	bschussek: yes one i have
Nov 18 11:48:09 <fabpot>	jmikola|w: I have one internally at Sensio
Nov 18 11:48:14 <beberlei>	the choices validator is rather weak on detecting the available choises
Nov 18 11:48:15 *	old_sound has quit (Quit: old_sound)
Nov 18 11:48:31 <beberlei>	say i have an entity with a many to one relation: BlogPost -> Author
Nov 18 11:48:35 <johanness>	fabpot: is there something coming regaring ACL on domain objects?
Nov 18 11:48:37 <beberlei>	and my form has a select dropdown
Nov 18 11:48:39 <bschussek>	beberlei: can you write a bug report?
Nov 18 11:48:46 <beberlei>	yah probably better
Nov 18 11:48:48 <beberlei>	or email
Nov 18 11:48:51 <Seldaek>	jmikola|w: the good ol' Sismo uh.. I hope you have time to make that public one day :)
Nov 18 11:48:51 <bschussek>	yes, thanks
Nov 18 11:49:10 <fabpot>	johanness: I have started something for Doctrine, but I did not had time to work on it. If someone want to work on that, that would be great
Nov 18 11:49:15 <mvrhov>	johanness, not good enough for inclusion?
Nov 18 11:49:25 <johanness>	fabpot: i can look into it
Nov 18 11:49:26 <Seldaek>	fabpot: ok that Sismo comment was for you not jmikola|w
Nov 18 11:49:28 <lsmith>	ok .. in theory we have one more topic that also got 6 votes .. which is flash messages .. but i think i could do a better job preparing that topic
Nov 18 11:49:48 <johanness>	maybe you can share the code you already have
Nov 18 11:49:54 <lsmith>	so i would repropose that topic for next week
Nov 18 11:50:11 <jmikola|w>	lsmith: i18n translation in messages?
Nov 18 11:50:14 <lsmith>	same as avalanche123's restful view and beberlei doctrine naming assumptions topic
Nov 18 11:50:26 <fabpot>	johanness: it's just one class that does not even work but send me an email and I will send it to you
Nov 18 11:50:30 <avalanche123>	yeah, that works
Nov 18 11:50:38 <lsmith>	jmikola|w: yeah .. the entire work flow for flash messages .. both with and without i18n .. and also how to best display them
Nov 18 11:50:50 <lsmith>	both in a central place in the layout and specific places in templates
Nov 18 11:51:33 <lsmith>	so with that .. i am closing todays meeting .. feel free to stay and chat :)
Nov 18 11:51:49 <fabpot>	thanks all for the nice chat and talk to you next week
Nov 18 11:51:58 <henrikbjorn>	the log Will go online?
Nov 18 11:52:01 *	fabpot has quit (Quit: fabpot)
Nov 18 11:52:04 <lsmith>	henrikbjorn: as always
Nov 18 11:52:12 <henrikbjorn>	thanks