You must first sign up to be able to contribute.


Doctrine ORM Bundle assumptions

Benjamin points out that the assumptions of filenames and locations are very strict, which prevents easy integration of third party Entities that for some reason do not fulfill these assumptions. Fabien agree's that this needs to be fixed. Benjamin explains out Doctrine does meta data reading and said he will work with Jonathan to get this issue resolved since others seem to agree as well that this is a problem

RESTful view handling

Bulat explained he was looking at HATEOAS which has as the "main ideas there is - uri = resource so /users/1.xml !== /users/1.json". They therefore propose to move output and version information into the headers. Fabien pointed out that while this may be correct in theory it doesn't work well with todays browsers. Jordi suggested that "it should still be possible to have the Accept header setting the _format". As for versioning Fabien said that "we can only have "standard" features in the framework" and since the versioning is a "userland" extension everybody agreed to not make this a core feature. Bulat volunteered to write up a patch to add accept header reading into _format.

Method naming conventions

Fabien said he has been working on applying method naming conventions in a branch, though most of these conventions had already been used across the code base. Everybody seemed to agree with the choices there, but proposed a few more scenarios. Jordi pointed out that for naming he is also concerned about how parameters are named: "request = $_POST, query = $_GET, attributes = routing". While the reasons for the naming are clear its hard to remember them. Jordi also raised that Bundle naming seems redundant: "Bundle/FooBundle/Bundle()". But Benjamin pointed out that the repition makes sense since one can have a "use" statement without an alias in which case the class name needs to be clear on its own. Johan also pointed out that container isn't such a clear concept making it unclear what get(). Bulat suggested potentially renaming the class from Container to ServiceContainer. However there was no agreement.

Flash messages and i18n

Jordi introduced the issue and the discussion focused on the issue of i18n for flash messages. Fabien said he would implement an optional Message class that could be used to set a flash message: "->setFlash('success', new Message('foo {{ bar }}', array('bar' => 12);" which would solve the i18n issue. However the Message class will not be coupled to the flash API at all. Jordi raised some concerns about performance using objects for such a case, but dropped the issue considering that with an object its easy to get the expected behavior for i18n in templates without much code.

Security component and SSO Options

Jeremy just quickly brought up that " the issue i had was username/password being in the basic user interface". Fabien pointed out that "username and password can be anything. Have a look at the certificates implementation for instance"

IRC logs

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
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 ( 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 (~webby@ 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>
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 ( 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>
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_ ( 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: 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 ( 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 ( 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 ( 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 ( 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 (, 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>
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:
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: 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