Created
November 17, 2011 17:17
-
-
Save jmikola/1373802 to your computer and use it in GitHub Desktop.
Log of #symfony-dev meeting 20111117 (all times GMT-5)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment