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

transcript.txt

Nov 17 11:01:04 <lsmith>	ok .. lets start
Nov 17 11:01:10 <lsmith>	first topic: [Config] added ability to set info message to node definition: http://bit.ly/nIuAcZ
Nov 17 11:01:24 <lsmith>	kbond: take it away :)
Nov 17 11:02:20 <kbond>	ok, just looking at some recent activity on the pr
Nov 17 11:02:55 <kbond>	looks like we will have to implement a new interface because the current one has @api set
Nov 17 11:03:20 *	rooster has quit (Remote host closed the connection)
Nov 17 11:04:00 <fabpot>	kbond: unfortunately, we cannot break the current API
Nov 17 11:04:04 <kbond>	right
Nov 17 11:04:32 <kbond>	like you say, a new interface will make it more complex - is that what we want to do?
Nov 17 11:05:31 <Stof>	kbond: "more complex" == adding an instanceof check in the command
Nov 17 11:06:24 <lsmith>	ok .. aside from this there are no more concerns before we can merge this?
Nov 17 11:06:26 <fabpot>	I think the added complexity is worth it as it means we are more BC
Nov 17 11:07:15 <lsmith>	we then still need a dump command .. right?
Nov 17 11:07:21 <beberlei>	from me looking at this the first time i dont think it adds measurable complexity to add this ismple interface
Nov 17 11:07:43 <beberlei>	kbond: are these info messages used in the exceptions when validation failes for a node?
Nov 17 11:07:54 <lsmith>	ah no .. there is already one in the PR
Nov 17 11:08:02 <couac>	isn't it to generate configuration doc ?
Nov 17 11:08:06 <Stof>	beberlei: the complexity is not in this PR. And it will not add much complexity in the dump command as it means simply doing an instanceof check before calling the dumper
Nov 17 11:08:06 <kbond>	for generating config yes
Nov 17 11:08:10 <couac>	nice
Nov 17 11:08:12 *	wilmoore has quit (Ping timeout: 240 seconds)
Nov 17 11:08:57 <kbond>	rudimentary config dump command based on this pr here: https://github.com/kbond/symfony/tree/config_dump_command
Nov 17 11:09:13 <couac>	Stof: so what's the matter with this PR ?
Nov 17 11:09:19 <beberlei>	couac: yes its for docs, but this might also help when an error is thrown, i dont know if it makes sense, its better then the technical error messages that exist currently.
Nov 17 11:10:03 <couac>	definitely
Nov 17 11:10:04 <kbond>	this pr just lets you set an info message to a node - that's it
Nov 17 11:10:07 *	jaugustin (c1a49c0c@gateway/web/freenode/ip.193.164.156.12) has joined #symfony-dev
Nov 17 11:10:12 <Stof>	well, we could reuse the help for the error, indeed
Nov 17 11:10:45 *	sblack (~sblack@206.207.84.3) has joined #symfony-dev
Nov 17 11:10:55 *	sblack (~sblack@206.207.84.3) has left #symfony-dev
Nov 17 11:11:03 <lsmith>	ok .. seems like we can move to the next topic
Nov 17 11:11:05 <beberlei>	from the given examples in the PR it doesnt make too much sense though
Nov 17 11:11:25 <lsmith>	Coordinating moving Doctrine*Bundle's to doctrine organization, adding Propel bridge
Nov 17 11:11:43 <lsmith>	beberlei: when do you plan to do the move? is there anything we need to keep in mind?
Nov 17 11:11:59 *	sacho_ (~sacho@92-247-246-203.spectrumnet.bg) has joined #symfony-dev
Nov 17 11:12:04 <lsmith>	do you need someone else do the actual coding? aka you could also just create the repo's and let someone else do the work
Nov 17 11:12:09 <Stof>	keeping it mind it will be a huge BC break for everyone to change the namespace :)
Nov 17 11:12:35 <Stof>	we should first ensure that existing PR related to Doctrine are merged if they are ready
Nov 17 11:12:40 <fabpot>	the other thing to keep in mind is that fixing something in the bundle will need to be done in two different repositories
Nov 17 11:12:41 <Stof>	to avoid loosing stuff
Nov 17 11:13:06 <fabpot>	so, yes, if we are aware of some stuff that need to be done, let's do them before
Nov 17 11:13:16 <lsmith>	can't the repo's be subtree merges of the current 2.0 code?
Nov 17 11:13:32 <lsmith>	then in theory it should still be possible to send 2.0 fixes to Symfony 2.0
Nov 17 11:13:37 <lsmith>	ah no never mind
Nov 17 11:13:39 <lsmith>	forget that :)
Nov 17 11:13:43 <beberlei>	moving the doctrine bundle will not be a BC at all, since there is no code that will be extended
Nov 17 11:13:53 <beberlei>	its just the DI Extension + Config and the commands
Nov 17 11:13:54 <lsmith>	beberlei: well the kernels will need to change
Nov 17 11:14:05 <Stof>	beberlei: all user-land code using the classes from DoctrineBundle
Nov 17 11:14:06 <lsmith>	and config .. like you say
Nov 17 11:14:11 <lsmith>	so its a big break .. but easy to fix
Nov 17 11:14:18 <Stof>	lsmith: config, probably not
Nov 17 11:14:20 <beberlei>	yes, but thats a one liner and easy to spot since you also have to change the deps file
Nov 17 11:14:27 <beberlei>	Stof: what code extends from DoctrineBundle?
Nov 17 11:14:36 <beberlei>	most of the code extends from the bridge, which will not move
Nov 17 11:14:43 <lsmith>	and type hints will need to change too for the Registry
Nov 17 11:14:52 <lsmith>	ah right
Nov 17 11:14:54 <beberlei>	the bundle only contains the DI extension + config and the commands
Nov 17 11:14:59 <Stof>	right
Nov 17 11:15:29 <Stof>	people typehinting the registry instead of the interface would have an issue but they were doing crap anyway :)
Nov 17 11:15:30 <beberlei>	i planned to create the bundle + repo tomorrow, since i have the whole day free to work on whatever
Nov 17 11:15:41 *	r1pp3rj4ck has quit (Quit: leaving)
Nov 17 11:15:43 <lsmith>	ok awesome
Nov 17 11:15:45 *	sacho has quit (Ping timeout: 240 seconds)
Nov 17 11:15:52 <beberlei>	but i kind of need to know the current timetable for a stable release of 2.1 and composer related moves in the master of symfony-standard
Nov 17 11:16:02 <Stof>	so only changing the kernel will be needed
Nov 17 11:16:05 <lsmith>	couac: i guess you will figure out whatever the dir is supposed to be called with fabpot and then thats done too
Nov 17 11:16:16 <couac>	yes
Nov 17 11:16:48 <Stof>	beberlei: first check DoctrineBundle PRs please
Nov 17 11:16:50 <couac>	it's ok for my part
Nov 17 11:16:55 <beberlei>	fabpot: yes i thought about this aswell, but the DIC code and the the bridge dont have too much overlaps that actually need fixes in both code bases, and if its mostly for added functionality from the bridge to be registered in the DIC
Nov 17 11:16:59 <fabpot>	beberlei: I don't have any schedule for 2.1 in mind but I think it won't be the LTS, so we can probably release one before the end of the year
Nov 17 11:17:23 <Stof>	so just after Doctrine 2.2 ?
Nov 17 11:17:26 <beberlei>	Stof: good point, will do that before starting
Nov 17 11:17:57 <beberlei>	doctrine 2.2 will be in december, we sort of dropping planned features now as to match the timetable
Nov 17 11:18:27 <Stof>	I will add one, btw. The EntityProvider should be moved to the bridge as changing the typehint and only one line makes it reusable for all projects
Nov 17 11:19:19 <beberlei>	where is that located currently?
Nov 17 11:19:25 <Stof>	and moving it before the split would be better for the history than removing it and readding it currently
Nov 17 11:19:32 <Stof>	isn't it in the bundle ?
Nov 17 11:19:35 <beberlei>	no
Nov 17 11:19:47 <Stof>	ok, then it is in the bridge but ORM specific
Nov 17 11:19:47 <beberlei>	its in the bridge
Nov 17 11:20:03 <Stof>	I will still do the PR, but it does not block the split
Nov 17 11:20:31 <lsmith>	ok .. anything else on that topic?
Nov 17 11:20:53 <beberlei>	fabpot: i dont see a large risk on the two code-base, the code got very stable in the 2.0 lifecycle and with all the additions and the interfaces we use in Doctrine and the registry being final now i dont think there is need for BC breaks in the feature that cause problems
Nov 17 11:21:29 <fabpot>	ok
Nov 17 11:21:33 <couac>	lsmith: is the Propel bridge PR mergeable right now?
Nov 17 11:21:55 <lsmith>	couac: not my call .. i dont care about the dir name .. if you and fabpot agree .. then i guess all is well :)
Nov 17 11:22:03 <Stof>	beberlei: there is no PR for DoctrineBundle anymore as my security PR has been merged
Nov 17 11:22:32 <lsmith>	ok next topic then .. [Security] UserInterface `equals` and Propel interface incompatibility
Nov 17 11:23:05 <Stof>	beberlei: in fact, there is one: yours https://github.com/symfony/symfony/pull/2535/files
Nov 17 11:23:07 <lsmith>	from what i read on twitter .. we agreed that we dont want to rename stuff in the UserInterface to please Propel .. but several people said they dont like the current name to begin with
Nov 17 11:23:27 <lsmith>	i dont remember what alternatives where mentioned
Nov 17 11:23:47 <couac>	isSameAs() no ?
Nov 17 11:23:48 <lsmith>	another point someone raised that this logic shouldnt even be in the model
Nov 17 11:23:50 <Stof>	someone suggested isSameUser
Nov 17 11:24:11 <lsmith>	but this would complicate implementations ..
Nov 17 11:24:29 <couac>	actually, there is no way to by pass that issue with Propel
Nov 17 11:24:29 <lsmith>	so maybe that would be taken things too far in terms of code purity
Nov 17 11:24:38 <Stof>	jwage was this one, saying it should be a UserComparator to handle it. But it would make things far more complicated
Nov 17 11:25:05 <fabpot>	+1 for renaming to avoid confusion, -1 to add yet another class/interface
Nov 17 11:25:07 <Stof>	as every people would need to implement a UserComparator fitting its needs
Nov 17 11:25:17 <Stof>	same vote
Nov 17 11:25:41 <couac>	same
Nov 17 11:25:53 <lsmith>	+1 for what fabpot said
Nov 17 11:26:00 <jmikola|w>	+1
Nov 17 11:26:18 <Stof>	btw, equals was a bit confusing as some people tried to implement it with === (even if the phpdoc explicitly warns against it)
Nov 17 11:26:52 <couac>	isSameUser() or isSameAs() is fine IMO
Nov 17 11:27:05 <lsmith>	ok
Nov 17 11:27:05 <lsmith>	so do we want to vote on a method name .. or leave a suggestion for whoever writes the PR?
Nov 17 11:27:05 <lsmith>	note the email that was recently send to the list about making sure that methods in interfaces are not too generic
Nov 17 11:27:12 <fabpot>	Can someone create a ticket or a PR?
Nov 17 11:27:22 *	dbu has quit (Read error: Connection reset by peer)
Nov 17 11:27:53 <beberlei>	especially on interface sthat domain objects extend this is important i guess
Nov 17 11:27:54 <Stof>	fabpot: will do
Nov 17 11:28:00 *	Couwtekx has quit (Quit: Leaving.)
Nov 17 11:28:02 <fabpot>	Stof: thanks
Nov 17 11:28:17 <lsmith>	to prevent conflicts
Nov 17 11:28:17 <lsmith>	so in that sense isSameUser() would be preferable
Nov 17 11:28:23 <Stof>	lsmith: this is why I prefer isSameUser than isSameAs
Nov 17 11:28:27 *	Couwtekx (~Adium@gut75-4-82-235-160-61.fbx.proxad.net) has joined #symfony-dev
Nov 17 11:28:59 <lsmith>	ok .. everzet doesnt seem to have updated his PR
Nov 17 11:28:59 <lsmith>	Resource watcher component: http://bit.ly/i6001p
Nov 17 11:29:22 <lsmith>	can we discuss it even without that? or move on to the next topic?
Nov 17 11:30:07 <Stof>	lsmith: I just pinged him on twitter to see if he can join us
Nov 17 11:30:19 *	johnkary (~johnkary@151.41.143.24.cm.sunflower.com) has joined #symfony-dev
Nov 17 11:30:25 <lsmith>	ok .. then the other topic with 3 votes is
Nov 17 11:30:26 <lsmith>	[HttpFoundation] Improve flash messages: http://bit.ly/vqnTFT http://bit.ly/sbNzAc
Nov 17 11:30:32 <lsmith>	drak is offline for the next few days
Nov 17 11:30:39 <lsmith>	but the second link is an alternative approach
Nov 17 11:31:02 <lsmith>	however i think we should spend the time coming to an agreement on the use cases
Nov 17 11:31:04 <lsmith>	and what we want to cover in core
Nov 17 11:31:11 <lsmith>	and what we want to make possible via extending
Nov 17 11:31:36 <beberlei>	there is no api examples in the PR
Nov 17 11:31:46 <beberlei>	how does this look like in templates with multiple messages pe rkey?
Nov 17 11:32:38 <Stof>	$flashBag->get('info') returns an array instead of a string
Nov 17 11:32:47 <Stof>	allowing to have several info messages
Nov 17 11:32:52 <fabpot>	as lsmith said, the first thing we need is the list of use cases and the ones we want to support in core
Nov 17 11:32:59 <beberlei>	how does this keep bc with session->setFlash() ?
Nov 17 11:33:12 <Stof>	it doesn't
Nov 17 11:33:18 *	rooster (~russ@cm-84.215.90.57.getinternet.no) has joined #symfony-dev
Nov 17 11:33:44 <Stof>	setFlash is now on the FlashBag in this PR
Nov 17 11:33:44 <lsmith>	here is fabpot's use case explanation https://github.com/symfony/symfony/pull/2592#issuecomment-2692200
Nov 17 11:34:10 <lsmith>	what i am missing from this explanation is where you do you exect the output to happen?
Nov 17 11:34:24 <lsmith>	in the layout?
Nov 17 11:34:26 <lsmith>	or where else?
Nov 17 11:34:29 <beberlei>	seriously no bc on this one? o_O its rather complex to change this everywhere necessary
Nov 17 11:34:31 <Stof>	the problem is here: currently a flash has a unique name and a value
Nov 17 11:35:02 <Stof>	I don't see the benefit of a unique name, whereas adding a type (info, warning...) is useful for the message
Nov 17 11:35:37 <Stof>	and using the name to store it means we can only have one message for each type
Nov 17 11:35:46 <johnkary>	+1 adding type. easier to target for view-related styling
Nov 17 11:35:58 <lsmith>	this to me is the crux .. in all my use cases i wanted to output the flash messages in the layout
Nov 17 11:36:06 <jmikola|w>	based on how trivial is is for the user to implement this themselves, i don't think core needs this (johannes__: https://gist.github.com/e8e11830614ba53661fa and mine: https://gist.github.com/388dc7f1ed977c396e7f)
Nov 17 11:36:08 <lsmith>	and therefore i need to know how to display the flash message
Nov 17 11:36:18 <jmikola|w>	a cookbook article sounds more sensible
Nov 17 11:36:19 <simensen>	one bundles idea of what "warning" means might be different than what you might want to expose.
Nov 17 11:36:22 *	nacmartin (~a@ppp-188-174-38-156.dynamic.mnet-online.de) has joined #symfony-dev
Nov 17 11:37:05 <lsmith>	jmikola|w: the problem .. is if its not in core .. you cannot rely on it .. meaning that inside your layout .. you will need to deal with all approaches that are used in any of the bundles you are using
Nov 17 11:37:06 <jmikola|w>	this is a case where different product requirements come into play for how a flash message or notification should behave, so i'm not optimistic that we'll find something to satisfy everyone
Nov 17 11:37:36 <pborreli>	so this "type" would be like a namespace for session attribute ?
Nov 17 11:37:38 <lsmith>	again guys please .. where do you display your flashes? in a generic template .. or in something bundle specific?
Nov 17 11:37:58 <jmikola|w>	lsmith: typically in a generic template
Nov 17 11:38:11 <jmikola|w>	but opensky never used controllers from other bundles
Nov 17 11:38:12 <VyacheslavSlinko>	yes, typically in general
Nov 17 11:38:16 <lsmith>	jmikola|w: right .. so a free for all means you need to modify every 3rd party bund;e
Nov 17 11:38:35 <jmikola|w>	if we were using admin bundle, i'd be inclined to tailor a layout to render its notification messages
Nov 17 11:38:39 <lsmith>	FOSUserBundle does for example
Nov 17 11:38:46 <lsmith>	admin bundles do too
Nov 17 11:38:51 <johnkary>	what if several bundles implemented different MessageManagers? you're stuck with more than 1 API to/from?
Nov 17 11:39:23 <jmikola|w>	if i was creating a bundle that printed flash messages, i'd probably expose my keys for info/error notifications as constants
Nov 17 11:39:27 <johnkary>	would it make a better thing to add to the framework bundle?
Nov 17 11:39:33 <jmikola|w>	so they could be fetched in any template
Nov 17 11:40:11 <Stof>	the point is that HttpFoundation should provide something useful. Otherwise let's drop it altogether.
Nov 17 11:40:25 <Stof>	and currently, the unique name is not very useful
Nov 17 11:40:39 <lsmith>	+1
Nov 17 11:40:53 <lsmith>	but i do think we need to have something in core
Nov 17 11:40:55 <jmikola|w>	Stof: i think this is outside the scope of the Http components - i forsee some kind of manager class, and that'd likely be in FrameworkBundle
Nov 17 11:40:58 <beberlei>	but adding a type is much more sensible than having a bag, i dont see how a bag solves the problem
Nov 17 11:41:22 <beberlei>	then somebody adds stuff to "error" the other to "fehler"
Nov 17 11:41:26 <jmikola|w>	after all, isn't this specific to form submissions or some write operations?
Nov 17 11:41:34 <Stof>	beberlei: the FlashBag solves a different thing: moving it outside the session to alow changing the implementation
Nov 17 11:41:36 <johnkary>	jmikola|w: +1  are "flash" in the http spec? or help support it? no. should be outside HttpFoundation
Nov 17 11:41:55 <lsmith>	beberlei: imho we should have a set of constants for "standard" types
Nov 17 11:41:55 <lsmith>	whos useage is optinal
Nov 17 11:42:04 <jmikola|w>	johnkary: they are in HttpFoundation via the Session class
Nov 17 11:42:28 <lsmith>	jmikola|w: well i agree that they probably shouldnt be in HttpFoundation .. so i am ok to move it out
Nov 17 11:42:33 <Stof>	jmikola|w: the other point is, do we really need it inside the session ?
Nov 17 11:42:46 <jmikola|w>	Stof: to save flashes between requests, wouldn't it have to be?
Nov 17 11:42:51 <Stof>	It seems like a message system would use the Session as deps, not the opposite
Nov 17 11:42:55 <jmikola|w>	ah, yes
Nov 17 11:42:56 <simensen>	If it is moved elsewhere I think it should be moved to someplace easy to integrate.
Nov 17 11:43:07 <beberlei>	still having types makes it 3 variables, key, type, value which is not easy to handle i ntwig
Nov 17 11:43:16 *	dbu (~david@194.230.159.80) has joined #symfony-dev
Nov 17 11:43:26 <lsmith>	beberlei: no .. its type + value
Nov 17 11:43:26 <simensen>	For example, Silex uses Session currently. How would moving it impact the ability for people to do flash messaging in Silex?
Nov 17 11:43:27 <jmikola|w>	I think a MessageManager service is called for, that would depend on Session - for this reason I suspect FrameworkBundle would be the place for it
Nov 17 11:43:31 <lsmith>	there is no need for a key
Nov 17 11:43:42 <Stof>	beberlei: there is one PR with key, type, value. The other is type => [value1, value2]
Nov 17 11:43:56 <jmikola|w>	simensen: i think the concept of flashes themselves could remain in the Session service - this is a layer of abstraction atop that
Nov 17 11:44:01 <lsmith>	btw .. indeed flash messages shouldnt require session .. in theory they should also be pushed to the client through some other means
Nov 17 11:44:12 <jmikola|w>	some people might want these messages to persist longer than one request, or some not even until the next request
Nov 17 11:44:25 <lsmith>	like websockets or cookies (both being more ESI friendly)
Nov 17 11:44:32 <Stof>	jmikola|w: my point is: should it be in the session or around it. i.e. a class receiving the session in it
Nov 17 11:44:41 <fabpot>	jmikola|w: no, flashes have one specific goal: storing something for the very next request when doing a get after a post
Nov 17 11:44:53 <jmikola|w>	fabpot: but we have non-persistent flashes, no?
Nov 17 11:45:00 <Stof>	jmikola|w: no
Nov 17 11:45:01 <jmikola|w>	Stof: I think the MessageManager would depend on Session
Nov 17 11:45:14 <lsmith>	jmikola|w: imho optionally
Nov 17 11:45:32 <Stof>	lsmith: several storages for the messages :)
Nov 17 11:45:40 <jmikola|w>	Stof: +1
Nov 17 11:45:40 <lsmith>	if you embed the flash message in the GET response after a form submission .. you cannot cache the response
Nov 17 11:45:42 <johnkary>	does Session implement an interface for storing keys that could be implemented by another datastore?
Nov 17 11:46:00 <Stof>	johnkary: what do you mean ?
Nov 17 11:46:22 <jmikola|w>	i dunno why i recalled some mechanism where flashes had the option of hanging around until the next request, or not persisting to the session
Nov 17 11:46:35 <johnkary>	interface with the methods used to store/persist the flash message:   e.g. getKey()  setKey()
Nov 17 11:46:54 <jmikola|w>	in practical use for messages, i know people sometimes want their messages to hang around beyond one request so that an AJAX request between pages doesn't lose the flash message
Nov 17 11:46:56 <Stof>	jmikola|w: this is johannes__'s message manager
Nov 17 11:47:09 *	asm89 has quit (Quit: bye!)
Nov 17 11:47:11 <Stof>	johnkary: flashes are persisted in the session in a special key
Nov 17 11:47:13 <johnkary>	that another class could implement to store their own persistent flashes, or to dump to another datastore like an in-memory store. (not saying this is a good idea nor warranted)
Nov 17 11:47:18 <Seldaek>	lsmith: I have to run, if the eventdispatcher thing comes up, I hope someone can speak for it, otherwise getting feedback on it from fabpot would be a start
Nov 17 11:47:21 *	rooster has quit (Ping timeout: 240 seconds)
Nov 17 11:47:32 <Stof>	and the the SessionStorage is used as for other session values
Nov 17 11:47:52 <johnkary>	ok nm out of scope :)
Nov 17 11:48:22 <lsmith>	ok .. i am seeing a lot of agreement of moving flash messages out of session
Nov 17 11:48:35 <lsmith>	fabpot: IIRC you also agreed on that .. right?
Nov 17 11:49:07 *	rooster (~russ@cm-84.215.90.57.getinternet.no) has joined #symfony-dev
Nov 17 11:49:07 <Stof>	btw, according of drak's comments on another request, we need to refactor the session storage too as it has a bunch of issues
Nov 17 11:49:14 <lsmith>	so there will be some BC break .. though i dont think with any of the discussed approaches we are talking about a big BC break
Nov 17 11:49:33 <mvrhov>	I've forgotten how zf does it but why don't we look how other  frameworks solved the issue?
Nov 17 11:49:44 <simensen>	So Session will no longer have the ability to get or set flash?
Nov 17 11:49:58 <lsmith>	mvrhov: fabpot checked Rails .. they have some special treatment for "notices"
Nov 17 11:50:13 <lsmith>	Drupal and Zikula both have a value stack for types
Nov 17 11:50:26 <mvrhov>	zf has specific types afair.. let me check the manual
Nov 17 11:50:38 <Stof>	lsmith: he agreed about moving it to irs own class. But the question remains: will this new class be injected in the session (drak's PR and the session doing special logic to store flashes) or will the session be injected in the new class receive the session
Nov 17 11:51:13 <Stof>	=> clean Session class and the flashBag is responsible to store the flashes in the session
Nov 17 11:51:13 <lsmith>	imho a listener should move the flash messages into the session
Nov 17 11:51:19 *	bshaffer|away is now known as bshaffer
Nov 17 11:51:42 <lsmith>	then you can easily also write the flash messages else where in order to get them to the user
Nov 17 11:52:14 <lsmith>	and another listener will then be responsible for removing the flash messages from the session on the next request
Nov 17 11:52:25 *	VyacheslavSlinko has quit (Quit: Leaving)
Nov 17 11:52:25 <Stof>	so IMO, the flash messages should not be the responsibility of the Session at all but the responsibility of another class in which the session is injected
Nov 17 11:52:42 <lsmith>	s/another class/a listener
Nov 17 11:52:42 *	VyacheslavSlinko (~Vyachesla@85.31.124.200) has joined #symfony-dev
Nov 17 11:53:29 <lsmith>	ok .. i guess this gives some basis for further work .. until fabpot wants to veto the current direction being discussed
Nov 17 11:54:02 <mvrhov>	zf has namespaces in its flash messenger
Nov 17 11:54:12 *	ellis has quit (Ping timeout: 240 seconds)
Nov 17 11:54:13 <mvrhov>	and then you put the messages into that namespace
Nov 17 11:54:24 <mvrhov>	there can be more than one message per namespace
Nov 17 11:54:33 <Stof>	lsmith: not *only* a listener. addFlash()... are what are in the FlashBag I talked about
Nov 17 11:55:05 <mvrhov>	http://pastebin.com/FUMB11M8 from ZF 1.11
Nov 17 11:55:09 <Stof>	a listener could be used to call $flashBag->save() if needed (and not sure it is even needed depending of the implementation)
Nov 17 11:55:17 *	Couwtekx1 (~Adium@gut75-4-82-235-160-61.fbx.proxad.net) has joined #symfony-dev
Nov 17 11:55:47 *	Couwtekx has quit (Read error: Connection reset by peer)
Nov 17 11:56:03 <lsmith>	did fabpot go afk?
Nov 17 11:56:17 <johnkary>	mvrhov: seems pretty similar to what symfony1 sfUser attributes were: http://trac.symfony-project.org/browser/branches/1.4/lib/user/sfUser.class.php
Nov 17 11:56:51 <lsmith>	since Seldaek just ran off .. the only other topic would be travis-ci .. but i guess i will have to write a detailed explanation of why jenkins and travis-ci are complementary
Nov 17 11:57:08 *	beberlei has quit (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
Nov 17 11:57:10 <lsmith>	so lets just continue talking about flash messages for the last few minutes
Nov 17 11:57:17 *	Couwtekx1 has quit (Client Quit)
Nov 17 11:59:10 <mvrhov>	the other issue I mentioned is also the translation of said messages
Nov 17 11:59:29 *	bshaffer is now known as bshaffer|away
Nov 17 11:59:42 <mvrhov>	as we somehow need to provide the parameters so translation can be done in view layer
Nov 17 11:59:59 *	sacho_ has quit (Read error: Connection reset by peer)
Nov 17 12:00:28 *	dbu has quit (Read error: Connection reset by peer)
Nov 17 12:00:33 <mvrhov>	it would really be nice if we could solve both issues at the same time