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

transcript.txt

Nov 25 10:59:28 <iampersistent>	OK, I think we can get started now
Nov 25 10:59:48 <iampersistent>	Just in case you don't know, the topics are picked by the number of votes
Nov 25 10:59:57 <iampersistent>	and each topic gets 15 minutes max
Nov 25 11:00:26 <iampersistent>	baberlei do you want to talk about the ORM Bundle assumptions?
Nov 25 11:00:29 <jmikola>	oh, did we start?
Nov 25 11:00:36 <jmikola>	just woke up :P
Nov 25 11:01:19 <iampersistent>	well no response, here is the background http://trac.symfony-project.org/ticket/8794
Nov 25 11:01:40 <iampersistent>	anyone have any input on this?
Nov 25 11:02:08 <jmikola>	so this ticket was asking for a way to disable the blanket auto-loading for each bundle, yes?
Nov 25 11:02:23 <rande>	I don't see the issue :/
Nov 25 11:02:39 <rande>	the metadata information will be cached at the end
Nov 25 11:02:48 <henrikbjorn>	beberlei:
Nov 25 11:02:49 *	avalanche123 ([email protected]) has joined #symfony-dev
Nov 25 11:03:03 <henrikbjorn>	avalanche123: u made it
Nov 25 11:03:07 <jmikola>	avalanche123: greetings, we've started on the ORM topic, you're next with Restful
Nov 25 11:03:09 <avalanche123>	hi!, have we started already:)&
Nov 25 11:03:10 <avalanche123>	?
Nov 25 11:03:20 <avalanche123>	awesome
Nov 25 11:03:32 <jmikola>	rande: i think the metadata itself is cached, but the scanning of directories happens each time, no?
Nov 25 11:03:33 <rande>	just now
Nov 25 11:03:47 <henrikbjorn>	I think we should take restful now beberlei is afk
Nov 25 11:03:48 <beberlei>	well i already had a chat about the assumptions with jonathan
Nov 25 11:04:00 <beberlei>	which lead to this ticket
Nov 25 11:04:05 <rande>	ok
Nov 25 11:04:23 <jmikola>	beberlei: have you talked with him since july 16th? :)
Nov 25 11:04:33 <beberlei>	by default the auto options are probably ok, however the conventions ar epretty strict
Nov 25 11:04:52 <beberlei>	and you can totally throw away the doctrine bundle when your code does not fullfill this constraints
Nov 25 11:05:29 <beberlei>	so say we have some kind of doctrine extensions repository which contain entities
Nov 25 11:05:43 <beberlei>	then there is no way to tell symfony doctrine2 bundle atm to register them
Nov 25 11:05:51 <jmikola>	unless it was a symfony bundle?
Nov 25 11:05:55 <beberlei>	because obviously they are not in MyBundle/Foo/Entities
Nov 25 11:05:56 *	webPragmatist ([email protected]) has joined #symfony-dev
Nov 25 11:05:56 *	webPragmatist has quit (Changing host)
Nov 25 11:05:56 *	webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev
Nov 25 11:05:58 <beberlei>	yes
Nov 25 11:06:32 <fabpot>	I think this is something we need to fix, as one good practice can be to totally decouple the Model/Entities from the bundles
Nov 25 11:07:05 <jmikola>	would you guys like to see the extra paths specified similar to how bundles are for kernels?
Nov 25 11:07:23 <jmikola>	perhaps within the DIC config for doctrine bundle?
Nov 25 11:07:45 <avalanche123>	yeah, I think it makes sense to allow users to register annotation namespaces through bundle config?
Nov 25 11:08:15 <beberlei>	there is the case to configure it on a per bundle basis, but also say if yo uhave your Application bundle only and want to use 2-3 extensions for doctirne that are not in a symfony bundle, then maybe some kind of global mechanism would help to
Nov 25 11:08:31 <beberlei>	for example if you check out some code into src/vendor/ADoctrineExtension/<EntitiesHere>
Nov 25 11:08:53 <avalanche123>	classes that use yaml or xml can be found through their metadata mappings
Nov 25 11:09:00 <fabpot>	beberlei: how would you do that when using Doctrine without Symfony?
Nov 25 11:09:03 <avalanche123>	only annotated classes are a problem
Nov 25 11:09:21 <henrikbjorn>	Like getBundleDirectories but for entities/documents
Nov 25 11:09:36 <jmikola>	i suppose you'd register metadata manually with PHP code, right?
Nov 25 11:09:38 <beberlei>	fabpot: you configure each xml, yaml, annotations driver explicitly by passing a single directory string or an array of strings
Nov 25 11:09:50 <beberlei>	if you only use one driver you pass this driver to the EntityManager
Nov 25 11:09:55 <fabpot>	henrikbjorn: or like inclusion system we have in the routing (annotations:...)
Nov 25 11:09:56 *	johan806 has quit (Read error: Operation timed out)
Nov 25 11:09:57 <beberlei>	if you use multiple drivers there is a composite object
Nov 25 11:10:08 <beberlei>	let me check for the docs or a test
Nov 25 11:10:13 <fabpot>	beberlei: so, why not exposing this mechanism in the bundle?
Nov 25 11:11:13 <avalanche123>	fabpot, that's what I was thinking about annotations: - in the config
Nov 25 11:11:24 <avalanche123>	or annotationNamespaces:
Nov 25 11:11:25 <beberlei>	http://www.doctrine-project.org/projects/orm/2.0/docs/reference/configuration/en#multiple-metadata-sources
Nov 25 11:11:57 <beberlei>	there are three variables in play here
Nov 25 11:12:14 <avalanche123>	beberlei, but for each driver you can register additional namespaces, no?
Nov 25 11:12:17 <beberlei>	path to the mapping files (or entites in case of annotations), the type of the mapping, and the namespace prefix of the entities
Nov 25 11:12:20 <avalanche123>	by registering them in the reader
Nov 25 11:12:27 <beberlei>	yes ther eis an addPath() method
Nov 25 11:12:50 <beberlei>	so in an ideal world you only need one instance per mapping driver type
Nov 25 11:12:53 <iampersistent>	just to give you a heads up, we have about 2 minutes left on this topic
Nov 25 11:12:57 <avalanche123>	right
Nov 25 11:13:01 *	johan653 ([email protected]) has joined #symfony-dev
Nov 25 11:13:21 <beberlei>	if you all agree that this is an important feature i will bug jwage about it or implement that in some way
Nov 25 11:13:26 <beberlei>	i am just not sure about how to configure it
Nov 25 11:13:27 <avalanche123>	beberlei I think just moving that option to configuration and documenting it would solve most of the issues with namespace/location limitations
Nov 25 11:13:53 <avalanche123>	yeah, that's the hardest part:)
Nov 25 11:14:11 <avalanche123>	you'll have to play with the syntax until it makes sense
Nov 25 11:15:00 <iampersistent>	beberlei, since you are going to touch base with jwage on this to move it forward, let move to the next topic
Nov 25 11:15:27 <iampersistent>	avalanche123, this is your topic, the RESTful view handling
Nov 25 11:15:34 <avalanche123>	ok
Nov 25 11:15:49 <avalanche123>	so I was reading on HATEOAS a lot recently
Nov 25 11:15:54 <avalanche123>	http://en.wikipedia.org/wiki/HATEOAS
Nov 25 11:16:08 <avalanche123>	and one of the main ideas there is - uri = resource
Nov 25 11:16:19 <avalanche123>	so /users/1.xml !== /users/1.json
Nov 25 11:16:27 <avalanche123>	as the uris are different
Nov 25 11:16:41 *	Dominique_ has quit (Read error: Connection reset by peer)
Nov 25 11:16:49 <avalanche123>	the solution they propose for output format handling is
Nov 25 11:16:56 <avalanche123>	to use Accept: headers
Nov 25 11:17:12 <avalanche123>	like Accept: application/html+xml - would return heml representation
Nov 25 11:17:12 *	Dominique_ ([email protected]) has joined #symfony-dev
Nov 25 11:17:15 <avalanche123>	of a resource
Nov 25 11:17:15 <fabpot>	avalanche123: that does not work
Nov 25 11:17:24 <fabpot>	this is a very well known problem
Nov 25 11:17:28 <avalanche123>	that's what I was wondering about
Nov 25 11:17:32 <fabpot>	and everybody has the same solution
Nov 25 11:17:37 <avalanche123>	fabpot, can  you briefly explain it?
Nov 25 11:17:46 <mvrhov>	fabpot, why not?
Nov 25 11:17:54 <fabpot>	we all know that adding .xml or .yml is not semantically correct, but this is the only viable solution
Nov 25 11:18:03 <fabpot>	I mean, as far as browsers are concerned of course
Nov 25 11:18:16 <Seldaek>	I think it should still be possible to have the Accept header setting the _format
Nov 25 11:18:22 <fabpot>	if you expose an API only for consumption by WS, then you can use Accept headers
Nov 25 11:18:27 <Seldaek>	not saying it should be the only way, for obvious reasons
Nov 25 11:18:30 <avalanche123>	but even browsers send the accept headers, no?
Nov 25 11:18:35 <fabpot>	Seldaek: correct
Nov 25 11:18:43 <henrikbjorn>	Couldnt we add the accept types as a _format if .json|xml isnt in the url?
Nov 25 11:18:45 <fabpot>	right now, we don't have the Accept header possibility
Nov 25 11:19:04 <fabpot>	I'm just saying that the current way is mandatory and that we can add the Accept header also for pure-WS API
Nov 25 11:19:10 <jmikola>	avalanche123, could you use a request listener and set the response type after checking the header? or that would require some glue?
Nov 25 11:19:32 <avalanche123>	jmikola - interesting, I believe I could
Nov 25 11:19:32 <henrikbjorn>	I think we should add it
Nov 25 11:19:33 <fabpot>	jmikola: implementation is quite simple
Nov 25 11:19:54 <fabpot>	support was present in symfony1 for some time
Nov 25 11:19:56 <jmikola>	henrikbjorn: your solution seems like the properly integrated solution should sf2 support this out of the box :)
Nov 25 11:20:01 <jmikola>	fabpot: for accept-header? 
Nov 25 11:20:09 <fabpot>	jmikola: yes
Nov 25 11:20:10 <avalanche123>	fabpot - there just needs to be a mechanism to register accept type and the format that it represents
Nov 25 11:20:26 <avalanche123>	also another interesting point
Nov 25 11:20:30 <avalanche123>	is api versioning
Nov 25 11:20:36 <henrikbjorn>	Jmikpla it belongs to the object that transform a request to a response imo
Nov 25 11:20:38 <avalanche123>	and pure rest evangelists
Nov 25 11:20:40 <fabpot>	avalanche123: everything already exists even in Symfon2 -- the only missing part is the parsing of the Accept header and the population of the _format attribute
Nov 25 11:20:49 <avalanche123>	fabpot, yeah, I know
Nov 25 11:20:58 <avalanche123>	it helped a lot to open my eyes now:)
Nov 25 11:21:02 <fabpot>	but this should be optional
Nov 25 11:21:08 <avalanche123>	yes
Nov 25 11:21:11 <avalanche123>	agreed
Nov 25 11:21:18 <avalanche123>	so - api versioning
Nov 25 11:21:21 <jmikola>	henrikbjorn: is that an object? i thought  that's what the kernel does itself via: request->route->controller->response :)
Nov 25 11:21:30 <avalanche123>	they don't believe /api/v1/users/1 is correct
Nov 25 11:21:40 <avalanche123>	since /api/v2/users/2
Nov 25 11:21:45 <avalanche123>	is now a different resource
Nov 25 11:21:58 <avalanche123>	the solution they propose is again - accept header
Nov 25 11:22:15 <avalanche123>	like Accepth: application/xml;v=2
Nov 25 11:22:15 <henrikbjorn>	If its a different verdion isnt it a different resoource?
Nov 25 11:22:22 <mvrhov>	but semantically it is a different resource
Nov 25 11:22:23 <avalanche123>	not in rest
Nov 25 11:22:31 <avalanche123>	well not really
Nov 25 11:22:35 <Seldaek>	henrikbjorn: nah, just the api is different, the representation might change, but the data is the same
Nov 25 11:22:40 <avalanche123>	say you just added more options to user resource
Nov 25 11:22:48 <avalanche123>	Seldaek is correct
Nov 25 11:23:03 <henrikbjorn>	If the representation change id say the data is different
Nov 25 11:23:05 <Seldaek>	if the data is different, then your two apis just can not coexist
Nov 25 11:23:05 <fabpot>	please, let's not argue about what REST is
Nov 25 11:23:19 <avalanche123>	as you can see, you just add the "v" parameter to the header
Nov 25 11:23:27 <johan653>	i guess you can check for the header and invoke a totally different kernel from your index.php for example
Nov 25 11:23:52 <avalanche123>	I was wondering if we could have multiple views of the same format?
Nov 25 11:23:59 <avalanche123>	sort of versioned views?
Nov 25 11:24:04 <avalanche123>	fabpot, don't kill me:)
Nov 25 11:24:08 <fabpot>	avalanche123: I will
Nov 25 11:24:13 <avalanche123>	lol
Nov 25 11:24:19 <johan653>	well maybe your action changes, then different views are not enough :)
Nov 25 11:24:35 <fabpot>	avalanche123: we can only have "standard" features in the framework
Nov 25 11:24:42 <fabpot>	supporting the Accept header is standard
Nov 25 11:24:45 <fabpot>	the versioning thing is not
Nov 25 11:24:53 <avalanche123>	fabpot, makes sense
Nov 25 11:25:06 <avalanche123>	*resolved*^)
Nov 25 11:25:30 <fabpot>	avalanche123: I will have a patch just after the DIC patch then, right? ;)
Nov 25 11:25:49 <avalanche123>	fabpot - the DIC will be done this weekend
Nov 25 11:25:55 <avalanche123>	for sure
Nov 25 11:25:58 <fabpot>	avalanche123: hehe, great news!
Nov 25 11:26:03 <avalanche123>	:)
Nov 25 11:26:10 <avalanche123>	johan653 - that is true, but my controllers are thin, so most of the changes are in the model itself
Nov 25 11:26:16 <avalanche123>	*ideally
Nov 25 11:26:35 <iampersistent>	anything else on this topic or shall we move on?
Nov 25 11:26:41 <avalanche123>	I'm done
Nov 25 11:26:44 <fabpot>	let's move on
Nov 25 11:27:03 <iampersistent>	ok Method naming conventions:http://bit.ly/hxmvOZ fabpot, I believe this is your topic
Nov 25 11:27:10 <fabpot>	yes
Nov 25 11:27:16 <fabpot>	this one is pretty simple
Nov 25 11:27:33 <fabpot>	This is about being coherent
Nov 25 11:27:47 <fabpot>	so that a developer can guess the method names easily
Nov 25 11:28:09 <jmikola>	fabpot: i agreed with the mailing list post, but as you had "The good news is that these conventions are already used"... i didn't see much to comment on :)
Nov 25 11:28:11 <fabpot>	for instance, right now, sometimes, we use delete(), and then some classes use remove() for the same method action
Nov 25 11:28:28 <fabpot>	jmikola: my point was about the names themselves
Nov 25 11:28:32 <fabpot>	are they good enough?
Nov 25 11:28:33 <Seldaek>	I honestly don't have much to say there, it seems all good.. and I'm really happy this happens btw
Nov 25 11:28:36 <fabpot>	would you want some others?
Nov 25 11:28:42 <avalanche123>	fabpot, you forgot to add 'supports()':)
Nov 25 11:29:02 <fabpot>	avalanche123: this is something different, but yes, this is also a "standard" one
Nov 25 11:29:05 <henrikbjorn>	Contains > has
Nov 25 11:29:16 <fabpot>	if there is no comment, I will merge my branch and we can move on
Nov 25 11:29:21 <jmikola>	i suppose one question is the pluralization... if it involves -ies, -es, or -s... you'd do whatever is english-ly correct?
Nov 25 11:29:31 <fabpot>	jmikola: correct
Nov 25 11:29:55 <johan653>	one example where this "main" relation thingy is not so clear is the "container", a container can contain about anything; without knowing that it's actually a "service container", you don't really have any expectation what ->get() does in this case
Nov 25 11:29:59 <jmikola>	and lastly, the only thing i can point out is:   replace()  -> setXXXs() 
Nov 25 11:30:15 <jmikola>	only case of the base method name changing for plural
Nov 25 11:30:25 <jmikola>	perhaps there's a better solution for that
Nov 25 11:30:44 <Seldaek>	fabpot: one somewhat related issue I have with naming, is the parameter jars on the Request class. request = $_POST, query = $_GET, attributes = routing, the rest is straightforward. But those three are very confusing imo. I know it's the correct naming, but I'm so used to $_GET & such, I always have to look it up to check if I'm correct
Nov 25 11:30:45 <johan653>	so the main problem i see is how do we identify the "main" relation
Nov 25 11:31:06 <Seldaek>	s/jars/bags/
Nov 25 11:32:07 <henrikbjorn>	Johan653 typehinting if its objects i think
Nov 25 11:32:49 <avalanche123>	fabpot, setParameter is still left on the container, since it calls ParameterBag::set(), right? should this convention be documented somewhere too?
Nov 25 11:33:08 *	wissl ([email protected]) has joined #symfony-dev
Nov 25 11:33:17 <avalanche123>	that all proxied methods look like set/get(ObjectName)
Nov 25 11:33:41 <Seldaek>	fabpot: another naming issue, is "the Bundle repeat" - Bundle/FooBundle/Bundle() - couldn't we at least do Foo instead of FooBundle?
Nov 25 11:34:12 <henrikbjorn>	Seldael please not
Nov 25 11:34:29 <Seldaek>	just a suggestion
Nov 25 11:34:42 <Seldaek>	more like curiosity
Nov 25 11:34:48 <Seldaek>	I'm not sure what's best really..
Nov 25 11:34:53 <Seldaek>	avalanche123: I think that's already mentioned as "
Nov 25 11:34:56 <Seldaek>	  * set()      -> setXXX()
Nov 25 11:35:05 <fabpot>	... I'm on the phone... brb
Nov 25 11:35:14 <henrikbjorn>	then rather the old naming of Bundle\Vendor\GooBundle\Bundle()
Nov 25 11:35:18 <avalanche123>	oops, gotta read more carefully:), thanks Seldaek
Nov 25 11:35:23 <jmikola>	johan653: the main relation is more of a logical thing i believe - surely the code could have type hints - but if you're a ParameterBag, the logical main relation is parameters
Nov 25 11:35:42 <Seldaek>	henrikbjorn: is that not still in anymore?
Nov 25 11:35:52 <johan653>	jmikola: and if you're a container? :)
Nov 25 11:35:59 <jmikola>	johan653: services :)
Nov 25 11:36:05 <henrikbjorn>	No its goobundle\goobundle()
Nov 25 11:36:20 <jmikola>	parameters are already secondary relations in DIC, as they have get/setParameter()... and main get/set are reserved for services
Nov 25 11:36:30 <johan653>	well, container is so abstract that without knowing the framework noone would know what it contains
Nov 25 11:36:50 <avalanche123>	johan653 - its a ServiceContainer
Nov 25 11:37:01 <johan653>	well yeah, but it's not named like that
Nov 25 11:37:09 <avalanche123>	so maybe if that class was called ServiceContainer it would resolve the issue?
Nov 25 11:37:23 <avalanche123>	fabpot how do you like ServiceContainer for DIC?
Nov 25 11:37:45 *	asynkritus ([email protected]) has joined #symfony-dev
Nov 25 11:37:51 *	lapistano has quit (Excess Flood)
Nov 25 11:38:10 <henrikbjorn>	Isnt it more about the var name in controllers?
Nov 25 11:38:12 <beberlei>	repetition in namespace and class name is not a bad thing imho
Nov 25 11:38:20 <beberlei>	since if you use "use", you only see the class name
Nov 25 11:38:32 <beberlei>	new Foo() is conceptionally void like new stdClass() imho
Nov 25 11:38:33 <henrikbjorn>	Beberlei it makes them long and tedius to write
Nov 25 11:38:38 <beberlei>	although new Bundle() is the same
Nov 25 11:38:39 <Seldaek>	beberlei: yeah, and also it avoids having 5 files opened all called Foo and not knowing which is what
Nov 25 11:38:47 *	lapistano ([email protected]) has joined #symfony-dev
Nov 25 11:38:56 <beberlei>	henrikbjorn: that is what autocomplete should be for :)
Nov 25 11:39:09 <jmikola>	this sounds like we're re-opening a mailing list discussion from the summer :)
Nov 25 11:39:10 <johan653>	beberlei: you can always use "as" in your "use" statement if you want a more expressive name
Nov 25 11:39:14 <henrikbjorn>	If you use a java ide proberly
Nov 25 11:39:20 *	asynkritus ([email protected]) has left #symfony-dev
Nov 25 11:39:29 <beberlei>	johan653: i dont like that for obfuscation reasons
Nov 25 11:39:31 <henrikbjorn>	Johan653 good point :)
Nov 25 11:40:01 <beberlei>	if i see a "Bundle" class i dont want to go up to the file only to see that its a shortcut for MyVeryLongBundle
Nov 25 11:40:11 <henrikbjorn>	Its the same with xml. Who really uses the schemas to get autocompletion
Nov 25 11:40:14 <avalanche123>	beberlei +1
Nov 25 11:40:17 <iampersistent>	we have just a couple of minutes left on this topic
Nov 25 11:40:23 <avalanche123>	henrikbjorn, I do:)
Nov 25 11:40:27 <johan653>	beberlei: how is using "as" here obfuscation?
Nov 25 11:40:41 <johan653>	i think this is a very good example for a valid use of "as"
Nov 25 11:40:43 <beberlei>	you dont see in the code that there was a rename, only whe inspecting the use
Nov 25 11:41:03 <fabpot>	The main relation for the Container is the services, not the parameters, so the main relation is very clear to me
Nov 25 11:41:03 <beberlei>	if you know nobody ever used AS then its simpler to navigate without having to look at all the use
Nov 25 11:41:05 <henrikbjorn>	Beberlei do you want bundle names like MyVendorNameReallyGoodBundle class names?
Nov 25 11:41:16 <avalanche123>	johan653 - I think its valid to "as" modify conflicting class names
Nov 25 11:41:31 <mvrhov>	henrikbjorn, :|
Nov 25 11:41:41 <iampersistent>	we need to wrap this topic and move to the next
Nov 25 11:41:41 <beberlei>	henrikbjorn: MyVendorName is the namespace, i let netbeans autogenerate the use statements for the class names
Nov 25 11:42:06 <johan653>	fabpot: it is clear if you know the what the container does, but if someone gives you just the name, then it's not
Nov 25 11:42:20 <henrikbjorn>	Beberlei thats how the bundle class should be named according to the docs
Nov 25 11:42:21 <fabpot>	johan653: but you never need to interact with the DIC
Nov 25 11:42:24 <fabpot>	directly
Nov 25 11:42:52 <beberlei>	henrikbjorn: including the vendor name? jus tthe bundle name i think
Nov 25 11:43:16 <henrikbjorn>	Incl the vendor name as i understand it and
Nov 25 11:43:17 <fabpot>	johan653: and if you do, then, you should probably know what this is about
Nov 25 11:43:22 <henrikbjorn>	-and
Nov 25 11:43:49 <iampersistent>	ok lets move on to Flash messages and i18n (http://bit.ly/cj3ZqT), this was left over from last week.  lsmith started this but Saldaek you probably know where he was coming from on this
Nov 25 11:44:07 <Seldaek>	weeell, I'll try to explain shortly then
Nov 25 11:44:12 <johan653>	fabpot: i just wanted to point out, that if we have no guideline for how we determine the "main" relation, then we have no real convention
Nov 25 11:45:01 <Seldaek>	if anyone is not up to date, basically the issue is that atm you pass flash messages as a simple key + string value, and we reckon there would be some extra parameters required in most cases, like at least a type (for styling), maybe other stuff (a count for translation/pluralization or something?)
Nov 25 11:45:24 <Seldaek>	so the idea was to add a few features to the flash messages, and also make them into an array or something a bit more complex than just a string
Nov 25 11:45:29 <henrikbjorn>	Isnt the key a typename? Like success or failure
Nov 25 11:45:45 <fabpot>	henrikbjorn: correct
Nov 25 11:45:54 <Seldaek>	what if you have multiple flash messages with success?
Nov 25 11:45:54 <jmikola>	Seldaek: they can't yet support the clever i18n syntax for handling pluralization automatically?
Nov 25 11:45:57 <Seldaek>	the key is unique afaik?
Nov 25 11:46:16 <Seldaek>	jmikola: you still need the count value, which should imo be attached to the flash message
Nov 25 11:46:18 <fabpot>	Seldaek: I don't see how you can have more than one
Nov 25 11:46:41 <Seldaek>	fabpot: fair enough, for most purposes I guess that is correct
Nov 25 11:46:42 <henrikbjorn>	Seldaek i cant either
Nov 25 11:46:48 <henrikbjorn>	Sry
Nov 25 11:47:07 <jmikola>	i'm not familiar with the current key-based implementation, but is it similar to validation components messages.[lang].xml ?
Nov 25 11:47:26 <fabpot>	so, the only problem is how to attach parameters for pluralization?
Nov 25 11:47:44 <Seldaek>	the issue with plurals imo is that, either you translate it in the controller (is this good?), or you need to pass the count
Nov 25 11:47:50 <Seldaek>	because maybe you display the messages in the layout
Nov 25 11:47:50 <jmikola>	if not, i don't see why would couldn't piggy-back how validation errors are printed - they also support variable replacement IIRC
Nov 25 11:47:58 <Seldaek>	and the layout doesn't know shit about the current page context
Nov 25 11:48:09 <henrikbjorn>	I can see the need for parameters for i18n
Nov 25 11:48:17 <Seldaek>	fabpot: there were also some proposed api changes by lsmith
Nov 25 11:48:55 <Seldaek>	http://groups.google.com/group/symfony-devs/msg/dd0adddd59d2496d
Nov 25 11:48:56 <fabpot>	Seldaek: flashes have only 1 use case: displaying something after a redirect
Nov 25 11:49:23 <avalanche123>	why not handle it the same way form handles validation messages?
Nov 25 11:49:36 <avalanche123>	with %varname% placeholders
Nov 25 11:49:37 <Seldaek>	avalanche123: I'm not sure how that is handled
Nov 25 11:49:51 <Seldaek>	fabpot: agreed there
Nov 25 11:50:03 <jmikola>	frankly, if i18n supports pluralization already, that's something forms could benefit from
Nov 25 11:50:17 <Seldaek>	I'm sorry if I can't provide enough context, maybe we just drop this and let lsmith present it next week
Nov 25 11:50:24 <fabpot>	->setFlash('success', new Message('foo {{ bar }}', array('bar' => 12);
Nov 25 11:50:31 <jmikola>	the last time i worked with Min/Max validators, i recall there not being a good way to pluralize if my number was 1 or greater
Nov 25 11:50:31 <Seldaek>	I didn't follow that stuff too closely..
Nov 25 11:50:56 <avalanche123>	fabpot, awesome!
Nov 25 11:51:04 <fabpot>	The Message class is called FieldError in the Validation component
Nov 25 11:51:09 <jmikola>	^ +1, that looks good
Nov 25 11:51:16 <fabpot>	The Message class can be part of the Translation Component
Nov 25 11:51:26 <Seldaek>	that'd be nice I think
Nov 25 11:51:39 <Seldaek>	although a bit scarily java-looking
Nov 25 11:51:45 <johan653>	is flash only intended for messages?
Nov 25 11:51:46 <jmikola>	fabpot: any reason they don't seem to inherit each other?  FieldError and Message, that is
Nov 25 11:52:01 <fabpot>	jmikola: Message does not exist... yet
Nov 25 11:52:05 <jmikola>	oh, Message , lol
Nov 25 11:52:05 <fabpot>	johan653: yes
Nov 25 11:52:16 <fabpot>	Seldaek: is it a problem?
Nov 25 11:52:19 <jmikola>	just tried to quick-open Message.php in eclipse and surprised myself
Nov 25 11:52:25 <johan653>	then i'd propose a better naming like setFlashMessage()
Nov 25 11:52:27 <Seldaek>	fabpot: can't this just be an array('message' => '..', 'parameters' => array(..))
Nov 25 11:52:43 <Seldaek>	I'm seriously worried about the object creep that seems to be occuring all over php
Nov 25 11:52:44 <henrikbjorn>	Please not
Nov 25 11:52:46 <johan653>	or even shorter, only setMessage()
Nov 25 11:53:04 <avalanche123>	Seldaek - objects are good:)
Nov 25 11:53:16 <fabpot>	Seldaek: and how do you manage it in the template? With an object, the i18n layer can do the good thing automatically.
Nov 25 11:53:31 <henrikbjorn>	setFlash(type, string, array) and use the message classe i. The setflash
Nov 25 11:53:35 <beberlei>	what object is ->setflash() on btw?
Nov 25 11:53:38 <rande>	maybe the object can be created automatically for simple text flash message
Nov 25 11:53:42 <henrikbjorn>	In the setflash method*
Nov 25 11:53:47 <johan653>	beberlei: session
Nov 25 11:53:52 <avalanche123>	beberlei - session
Nov 25 11:54:06 <Seldaek>	fabpot: yeah I know, objects are nicer, I just don't know how that'll all perform in the end, but so far it seems fast enough so whatever
Nov 25 11:54:09 <fabpot>	rande: for simple cases, you can still use the older syntax: setFlash('foo', 'bar');
Nov 25 11:54:33 <fabpot>	my proposal is to support both the current syntax, and the one with an object
Nov 25 11:54:33 <avalanche123>	Seldaek - I'd rather we optimize when see a problem than prematurely
Nov 25 11:54:37 <johan653>	Seldaek: one message wont kill you :)
Nov 25 11:54:40 <Seldaek>	sure
Nov 25 11:54:46 <Seldaek>	it's just about the attitude
Nov 25 11:55:13 <Seldaek>	anyways, let's drop this, if fabpot and others agree to do that Message thing, I think me or lukas can provide a patch tomorrow
Nov 25 11:55:33 <fabpot>	Seldaek: ok, so you work on that?
Nov 25 11:55:39 <jmikola>	one suggestion
Nov 25 11:56:09 <jmikola>	since there may be other reasons to generate a message in the controller, not just setting flash but perhaps a JSON response message... can we make message easily usable in a general context?
Nov 25 11:56:20 <fabpot>	Seldaek: I can work on a patch tomorrow, no problem
Nov 25 11:56:39 <Seldaek>	fabpot: well if you want go for it, I'm not too sure how to do the output part atm
Nov 25 11:56:40 <fabpot>	jmikola: the Message class will have nothing to do with Flashes
Nov 25 11:56:41 <jmikola>	i assume that would require at least the controller working with an interpolator  serviceon the message object?
Nov 25 11:56:51 <fabpot>	Seldaek: ok, I will work on a patch
Nov 25 11:57:21 <fabpot>	{{ foo|trans }} for instance will work natively with a string or a Message object
Nov 25 11:57:22 <jmikola>	fabpot: understood; i'm sure the message object will be nicely independent :)
Nov 25 11:57:35 <iampersistent>	we have just a couple of minutes left
Nov 25 11:57:42 <Seldaek>	fabpot: alright, yeah I could do that then;)
Nov 25 11:57:45 <iampersistent>	any thoughts before we wrap?
Nov 25 11:57:57 <jmikola>	iampersistent: my security topic was a single question
Nov 25 11:58:05 <iampersistent>	ok
Nov 25 11:58:07 <jmikola>	and i have to catch a train in 20 min, so i'm short myself and won't drag on :)
Nov 25 11:58:38 <jmikola>	fabpot: you said security component can support these SSO, etc methods out of the box, but the issue i had was username/password being in the basic user interface: https://github.com/fabpot/symfony/blob/master/src/Symfony/Component/Security/User/AccountInterface.php
Nov 25 11:59:10 <fabpot>	jmikola: what's the problem?
Nov 25 11:59:13 <jmikola>	the basic token interface seems to be username/password agnostic, which is great, but i'm wondering if i'd have to use this account interface
Nov 25 11:59:40 *	Garfield-fr has quit (Quit:  ⏏)
Nov 25 11:59:40 <jmikola>	if none of my auth methods utilizes usernames/passwords, would i just have to stub getUsername/getPassword methods and never use them?
Nov 25 11:59:45 <fabpot>	jmikola: username and password can be anything. Have a look at the certificates implementation for instance
Nov 25 12:00:03 <johan653>	jmikola: you don't have to use this interface
Nov 25 12:00:15 <jmikola>	do you have a quick class name i can reference?
Nov 25 12:00:21 <mvrhov>	and I believe that you'll at least nead a username
Nov 25 12:00:38 <jmikola>	i just had a hard time finding alternative examples in the component code - and no docs other than your slideshare presentation
Nov 25 12:00:39 <fabpot>	jmikola: X509
Nov 25 12:00:43 <iampersistent>	we'll put Chunked responses and ESI:http://bit.ly/hdnS48 on for next week
Nov 25 12:00:47 <iampersistent>	thanks everyone
Nov 25 12:00:57 <jmikola>	thanks fabpot , good to go on
Nov 25 12:01:01 <avalanche123>	thanks guys
Nov 25 12:01:02 <jmikola>	and thanks iampersistent for moderating
Nov 25 12:01:06 <jmikola>	i'll gist the logs in a second
Nov 25 12:01:12 <avalanche123>	thanks iampersistent
Nov 25 12:01:21 <fabpot>	thank you all
Nov 25 12:01:22 <iampersistent>	your welcome
Nov 25 12:01:29 <avalanche123>	thanks fabpot