Created
March 24, 2011 17:00
-
-
Save jmikola/885423 to your computer and use it in GitHub Desktop.
Log of #symfony-dev meeting 20110324 (all times GMT-4)
This file contains hidden or 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
| Mar 24 12:00:46 <lsmith> so lets go | |
| Mar 24 12:01:09 <lsmith> Response sub-classes vs. exceptions for HTTP status codes: http://bit.ly/eeo28C | |
| Mar 24 12:01:12 <lsmith> fabpot: ping | |
| Mar 24 12:01:18 <lsmith> kriswallsmith: ping | |
| Mar 24 12:01:23 <fabpot> pong | |
| Mar 24 12:01:27 <kriswallsmith> pong | |
| Mar 24 12:01:30 <beberlei> oink | |
| Mar 24 12:01:48 <lsmith> i guess both fabpot and kriswallsmith now think we shouldnt do this | |
| Mar 24 12:01:58 <kriswallsmith> yes, it takes control away from the user | |
| Mar 24 12:02:04 <fabpot> I created the 2 pull requests because I was not sure | |
| Mar 24 12:02:05 <lsmith> leaving me (and maybe Seldaek) who also think we should do this | |
| Mar 24 12:02:25 * johnkary ([email protected]) has joined #symfony-dev | |
| Mar 24 12:02:29 <fabpot> I think this is more a documentation problem, than a technical one | |
| Mar 24 12:02:33 <lsmith> kriswallsmith: well we direct things to a central place by default | |
| Mar 24 12:02:46 <jmikola|w> is the argument against using sub-classes? | |
| Mar 24 12:02:54 <jmikola|w> i see nothing in the ML link other than Jordi's +1 | |
| Mar 24 12:03:03 <Seldaek> jmikola|w: it's in the PR | |
| Mar 24 12:03:08 <fabpot> jmikola|w: everything is in the PRs | |
| Mar 24 12:03:08 <kriswallsmith> the centralized solution is there unless the user opts out of it by returning a response | |
| Mar 24 12:03:25 <kriswallsmith> so, +1 for addressing in documentation | |
| Mar 24 12:03:45 <Seldaek> and for my part, I'm not sure anymore if it's a good idea.. I think if we tell people to use exceptions, then it's ok if 4xx/5xx responses don't follow the same path, those are for more advanced use cases imo where you want to control everything | |
| Mar 24 12:04:14 <Seldaek> and in that case, I don't want my web service to return an exception page, I want to return a 405 and that's it | |
| Mar 24 12:04:16 <lsmith> johanness: ping | |
| Mar 24 12:04:31 <jmikola|w> is johanness' point about firewall needing to catch its access denied exception still valid? or was he opting to use security-specific exceptions instead | |
| Mar 24 12:04:32 <johanness> i don't see the point in doing that via documentation. if we don't want users to return error responses then we should disallow it | |
| Mar 24 12:05:11 <lsmith> johanness: well its not that we dont want them to do that | |
| Mar 24 12:05:14 <fabpot> johanness: that's what my PR does | |
| Mar 24 12:05:17 <lsmith> its just that we want to prevent surprises | |
| Mar 24 12:05:19 <Seldaek> johanness: I don't see why it should be prevented, it just means you don't use the framework exception handler, but an error response isn't really an exception, it's just a response to the client to tell it that something went wrong | |
| Mar 24 12:05:29 <lsmith> but i can live with it being handled by documentation .. | |
| Mar 24 12:05:39 <lsmith> though i think we could just as well document how to undo the default | |
| Mar 24 12:05:46 <kriswallsmith> i don't think users will be surprised if the core.exception event isn't fired when an exception isn't thrown | |
| Mar 24 12:05:55 <johanness> fabpot, yeah i would change that to always throw a 500 exception saying that the user should throw an exception instead of return a response | |
| Mar 24 12:06:06 <lsmith> but i guess the PR handles hiding a user error while forcing advanced users to change defaults | |
| Mar 24 12:06:17 <Seldaek> kriswallsmith: yeah that's definitely true, the current way (pre-PR) is at least straightforward | |
| Mar 24 12:06:27 <kriswallsmith> i don't think that level of strictness is necessary johanness | |
| Mar 24 12:06:54 <johanness> kriswallsmith, but we want users to do that | |
| Mar 24 12:07:07 <johanness> why should we put that into the documentation otherwise? | |
| Mar 24 12:07:07 <lsmith> johanness: the question is do we? | |
| Mar 24 12:07:11 <kriswallsmith> it doesn't matter if they throw an exception or a response, it's up to them | |
| Mar 24 12:07:14 <jmikola|w> even internally, sf2 will not convert exceptions into error-specific response subclasses... it'll just be response objects with appropriate 4xx or 5xx error codes? | |
| Mar 24 12:07:31 <lsmith> for example returning a 405 response .. could be a way for json/xml requests to by pass the exception listener | |
| Mar 24 12:07:38 <lsmith> since most likely you dont want it triggered there | |
| Mar 24 12:07:56 <kriswallsmith> we shouldn't for a user into more abstraction | |
| Mar 24 12:08:01 * bschussek has quit (Quit: May the force be with you) | |
| Mar 24 12:08:08 <fabpot> jmikola|w: the question is not whether we need to create sub-classes or not; it's if we force developer to use exception for 4xx/5xx | |
| Mar 24 12:08:24 <lsmith> we should also not just focus on this aspect .. | |
| Mar 24 12:08:25 <lsmith> http://www.google.com/url?sa=D&q=https://github.com/symfony/symfony/pull/369 | |
| Mar 24 12:08:26 <jmikola|w> reading through PR370, i'm in favor of core.exception functioning like core.view... it only steps in if an exception is received; i don't think strictness is necessary | |
| Mar 24 12:08:50 <lsmith> pull 370 is fairly clear cut .. you either favor one or the other | |
| Mar 24 12:08:54 <johanness> kriswallsmith, imo if we keep the flexibility, there is no point in advocating one solution over the other, e.g. we shouldn't put anything into the documentation | |
| Mar 24 12:08:58 <lsmith> PR 369 is a bit trickier from my POV | |
| Mar 24 12:09:18 <jmikola|w> fabpot: there seem to be many more 4xx and 5xx codes than we'd have exceptions for out of the box anyway... it might be limiting to mandate exceptions | |
| Mar 24 12:09:53 <fabpot> jmikola|w: read my post on the ML, everything is explained there | |
| Mar 24 12:10:46 <lsmith> johanness/fabpot: did you find a common ground on PR 369? | |
| Mar 24 12:10:51 <lsmith> and if so .. what is it? | |
| Mar 24 12:11:02 * kertz has quit (Ping timeout: 240 seconds) | |
| Mar 24 12:11:09 <jmikola|w> fabpot: yes, i see the list of what exceptions you're choosing to implement | |
| Mar 24 12:11:10 <fabpot> lsmith: not yet | |
| Mar 24 12:11:19 <johanness> we first need to settle on a general strategy imo | |
| Mar 24 12:11:23 <lsmith> ok | |
| Mar 24 12:11:47 <kriswallsmith> should be be concerned that http exceptions can be thrown from anywhere in the application? | |
| Mar 24 12:11:54 <kriswallsmith> i.e. from the model? | |
| Mar 24 12:11:55 <lsmith> so lets vote on PR 370 .. solve this by documentation or by forcing all 4x, 5x responses through the exception listener? | |
| Mar 24 12:12:07 * henrikbjorn ([email protected]) has joined #symfony-dev | |
| Mar 24 12:12:19 <johanness> lsmith, what does "solve this by documentation" mean? | |
| Mar 24 12:12:26 <kriswallsmith> is this a community decision? | |
| Mar 24 12:12:42 <lsmith> johanness: document that if you want the exception listener triggerd .. throw an exception | |
| Mar 24 12:12:51 <lsmith> if you dont ... return a response | |
| Mar 24 12:13:02 * M00nShield has quit (Ping timeout: 240 seconds) | |
| Mar 24 12:13:30 <iAsterisk> why should response go through an exception listener? | |
| Mar 24 12:13:43 <fabpot> ok, let's stop this discussion, it's going nowhere | |
| Mar 24 12:14:00 <iAsterisk> from the outside it looks confusing. | |
| Mar 24 12:14:04 <fabpot> I'm going to close PR 370 and let things as they are now | |
| Mar 24 12:14:05 <lsmith> yes .. thats why i was asking for a vote | |
| Mar 24 12:14:10 <lsmith> ok | |
| Mar 24 12:14:11 <kriswallsmith> sounds good, let's move on | |
| Mar 24 12:14:24 <lsmith> what about PR 369? | |
| Mar 24 12:14:31 <lsmith> anything we can discuss here to move things along? | |
| Mar 24 12:15:07 <lsmith> ok .. since nobody is speaking up | |
| Mar 24 12:15:09 <lsmith> next topic | |
| Mar 24 12:15:11 <lsmith> Review: Services naming: http://bit.ly/hfvVK8 | |
| Mar 24 12:15:17 <kriswallsmith> i'm still recusing myself from all security stuff | |
| Mar 24 12:16:10 <lsmith> i guess here the main question is if anyone is willing to spear head this? | |
| Mar 24 12:16:20 <lsmith> aka look through the list that jordi generated | |
| Mar 24 12:16:22 <Seldaek> yeha, I did my part with the grepping :p | |
| Mar 24 12:16:31 <henrikbjorn> define the naming, wasnt it about making some of them less verbose ? | |
| Mar 24 12:16:32 <lsmith> and try to find common naming patterns | |
| Mar 24 12:16:35 <lsmith> maybe document them | |
| Mar 24 12:16:36 <fabpot> lsmith: I will do that, it's on my todo list already | |
| Mar 24 12:16:43 <lsmith> ok | |
| Mar 24 12:16:49 <lsmith> then there is nothing to discuss there either? | |
| Mar 24 12:16:49 <everzet> cool | |
| Mar 24 12:17:02 <Seldaek> yeah I think it's good if fabpot can find time to do it, he has the best overview of everything | |
| Mar 24 12:17:09 * DrRotmos ([email protected]) has joined #symfony-dev | |
| Mar 24 12:17:18 <lsmith> then moving on .. | |
| Mar 24 12:17:24 <kriswallsmith> re: doctrine.odm.mongodb.default_document_manager, should we create a persistence manager-manager? | |
| Mar 24 12:17:27 <Seldaek> fabpot: if you manage to pull out some naming-conventions out of it to add to the docs, even better | |
| Mar 24 12:17:47 <everzet> Seldaek: +1 | |
| Mar 24 12:17:49 <Seldaek> 'cause I've seen lots of horrible things done in bundles by random people | |
| Mar 24 12:17:50 <fabpot> Seldaek: I will try to find some naming conventions for sure | |
| Mar 24 12:17:52 * kertz ([email protected]) has joined #symfony-dev | |
| Mar 24 12:18:02 <lsmith> next topic then: Whats missing for RC1? | |
| Mar 24 12:18:11 <lsmith> not sure if anything has changed since last week really | |
| Mar 24 12:18:16 <henrikbjorn> kriswallsmith: would be nice, but confusing if you use odm and orm at the same time | |
| Mar 24 12:18:17 <Seldaek> forms, but nvm :) | |
| Mar 24 12:18:22 <kriswallsmith> i think all public services should use only _ no . | |
| Mar 24 12:18:38 <Seldaek> kriswallsmith: ah weird, I liked the dots | |
| Mar 24 12:18:55 <Seldaek> I think they denote nesting much better than underscores | |
| Mar 24 12:18:56 <fabpot> I have converted many components to private usage | |
| Mar 24 12:18:56 <jmikola|w> kriswallsmith: dots are helpful for namespacing | |
| Mar 24 12:18:57 <everzet> kriswallsmith: dots is better | |
| Mar 24 12:19:06 <everzet> kriswallsmith: *ARE better | |
| Mar 24 12:19:11 <fabpot> but some still need to be done: Serializer, Form, and Validation | |
| Mar 24 12:19:20 <kriswallsmith> we should have very few public services | |
| Mar 24 12:19:22 <Seldaek> aye, it's on my todo | |
| Mar 24 12:20:05 <Seldaek> kriswallsmith: still, it just feels more natural to use <some_ns>.<name>, looks like twig variables | |
| Mar 24 12:20:08 <henrikbjorn> private = cant be changed or ? | |
| Mar 24 12:20:11 <lsmith> anything else that has changed since last week in terms of getting to RC1? | |
| Mar 24 12:20:21 <lsmith> fabpot: one question .. so the next release will be called beta1? | |
| Mar 24 12:20:23 <lsmith> or RC1? | |
| Mar 24 12:20:25 <Stof> henrikbjorn: can't be retrieved at runtime | |
| Mar 24 12:20:31 <henrikbjorn> ok | |
| Mar 24 12:20:34 <lsmith> and if beta1 .. will we also have an RC phase? | |
| Mar 24 12:20:38 * mapi_ has quit (Ping timeout: 255 seconds) | |
| Mar 24 12:20:40 <everzet> lsmith: RC without beta's is quite extreme :-) | |
| Mar 24 12:20:42 <fabpot> lsmith: beta1 as we won't have the service renames for instance | |
| Mar 24 12:20:43 <lsmith> just because i have seen some people wondering | |
| Mar 24 12:20:51 <lsmith> ok | |
| Mar 24 12:20:54 <everzet> lsmith: but i think our current PR's is already beta's | |
| Mar 24 12:20:55 <fabpot> some betas and then some RCs | |
| Mar 24 12:21:19 <lsmith> ok .. then moving on to the next topic -> why parameters.ini? http://bit.ly/ghx4dx | |
| Mar 24 12:21:21 <fabpot> everzet: beta means that all features are there but with bugs ;) | |
| Mar 24 12:21:31 <Seldaek> fabpot: ah right, something I wanted to mention, I've seen so many people asking when/what about the final, I think they deserve an update on the official blog to say what's the current state | |
| Mar 24 12:21:45 <Seldaek> because we are all up to speed here, but the users at large aren't | |
| Mar 24 12:21:45 <everzet> fabpot: it's strange, but i was always thought it is RC :-D | |
| Mar 24 12:22:04 <fabpot> everzet: RC means that we won't break BC | |
| Mar 24 12:22:14 * nostrzak ([email protected]) has joined #symfony-dev | |
| Mar 24 12:22:21 <lsmith> fabpot: basically many of us have been wondering why the SE uses ini format | |
| Mar 24 12:22:24 <fabpot> Seldaek: right, I will do that when announcing the beta1 next week | |
| Mar 24 12:22:32 <lsmith> what is the motivation for this? | |
| Mar 24 12:22:34 <Seldaek> ok cool | |
| Mar 24 12:22:43 <lsmith> given the flexibility of ini parsing in php 5.3 .. | |
| Mar 24 12:22:48 <everzet> fabpot: :-D Ok. It's just me. I've thought that beta is just betta than nothing... | |
| Mar 24 12:22:49 <fabpot> lsmith: because some people don't like YAML, some others don't like XML, and many don't like PHP for configuration | |
| Mar 24 12:22:50 * rouffj ([email protected]) has joined #symfony-dev | |
| Mar 24 12:22:52 <lsmith> i dont really see much difference between ini and yaml | |
| Mar 24 12:23:11 <fabpot> and I don't want people to not use Symfony just because the first thing the see is a YAML/XML file | |
| Mar 24 12:23:34 <Stof> then do all config in ini, not just one of the files :) | |
| Mar 24 12:23:40 <lsmith> well and what about the people that dont like ini for app config? | |
| Mar 24 12:23:57 <henrikbjorn> well they can see all formats | |
| Mar 24 12:24:04 <henrikbjorn> so they know they can choose whatever they want | |
| Mar 24 12:24:13 <everzet> lsmith: if you know how to configure Symfony2 app in yaml - you will be able to remove this ini simple | |
| Mar 24 12:24:18 <lsmith> i think adding a 4th format is adding confusion | |
| Mar 24 12:24:27 <fabpot> I think everybody can understand the goal of a simple ini file, it's just to be able to configure the required settings | |
| Mar 24 12:24:29 <everzet> lsmith: but if you don't (very begginer) - ini is a good starting point | |
| Mar 24 12:25:02 <everzet> lsmith: i think it's not about 4th format. It's about single configuration file for beginners. | |
| Mar 24 12:25:06 <pgodel_work> an explanation would aid in avoiding confusion | |
| Mar 24 12:25:32 <lsmith> i think our flexibility with formats is a plus | |
| Mar 24 12:25:33 <srohweder> thfo the beginners you can include one yml and hide the complicated stuff in imports | |
| Mar 24 12:25:38 <Seldaek> I guess the ini file is ok for standard distro maybe, but shouldn't be there in the others | |
| Mar 24 12:25:41 <ajessu> I like it for beginners.. it's easy to copy and paste (think tabs vs spaces in yaml) and very easy to understand right away | |
| Mar 24 12:25:43 <lsmith> but at the same time its confusing as hell for beginners already | |
| Mar 24 12:25:44 <ajessu> just to get started | |
| Mar 24 12:26:11 <lsmith> sure an ini file is something they will have seen with their php.ini | |
| Mar 24 12:26:12 <pgodel_work> but it is confusing because there is no explanantion and it was a suprise for us | |
| Mar 24 12:26:24 <Seldaek> on the other hand, all the sf1 users are used to yaml.. | |
| Mar 24 12:26:31 <everzet> lsmith: yeah. We need to tell them not to open other *.yml stuff before they'll become mature | |
| Mar 24 12:26:33 <pgodel_work> but I think it is easily addressable by documeting properly | |
| Mar 24 12:26:34 <lsmith> anyway .. | |
| Mar 24 12:26:42 <lsmith> either we vote on it .. or let fabpot decide | |
| Mar 24 12:26:46 <lsmith> no reason to keep talking about this | |
| Mar 24 12:26:47 <henrikbjorn> +1 | |
| Mar 24 12:26:51 <everzet> +1 | |
| Mar 24 12:26:51 <henrikbjorn> for ini | |
| Mar 24 12:27:00 <fabpot> +1 | |
| Mar 24 12:27:01 * old_sound has quit (Quit: old_sound) | |
| Mar 24 12:27:02 <ajessu> +1 | |
| Mar 24 12:27:04 <srohweder> 0 | |
| Mar 24 12:27:04 <lsmith> -1 for .ini | |
| Mar 24 12:27:05 <beberlei> +1 for ini | |
| Mar 24 12:27:06 <snc_hw> but then my issue should be fixed | |
| Mar 24 12:27:06 <avalanche123> +1 | |
| Mar 24 12:27:09 <igorw> -1 for ini | |
| Mar 24 12:27:25 <snc_hw> escape the "=" in the configurator | |
| Mar 24 12:27:30 <lsmith> ok voting ending in 10 | |
| Mar 24 12:27:39 <lsmith> 5 | |
| Mar 24 12:27:53 <lsmith> 0 | |
| Mar 24 12:27:56 <lsmith> ok .. ini stays | |
| Mar 24 12:27:59 <lsmith> next topic | |
| Mar 24 12:28:02 <lsmith> "core" dev meeting in Paris: http://bit.ly/ijZxVR | |
| Mar 24 12:28:17 <lsmith> basically i tried to remind us of our decisions from paris | |
| Mar 24 12:28:27 * srohweder has quit (Quit: leaving) | |
| Mar 24 12:28:39 <lsmith> i guess the "core bundle names" still need to be fixed | |
| Mar 24 12:28:45 <lsmith> aka we wanted to also prefix them with Symfony | |
| Mar 24 12:28:50 * ornicar has quit (Quit: WeeChat 0.3.4) | |
| Mar 24 12:28:56 <lsmith> fabpot: i will open a ticket for this? | |
| Mar 24 12:29:27 <lsmith> bridges have started to be created .. i guess each person responsible for a bundle/component can take care of that themselves? | |
| Mar 24 12:29:33 <fabpot> lsmith: but the problem is that everything will be prefixed with symfony_ in config files | |
| Mar 24 12:29:49 <Seldaek> fabpot: is this really a problem? | |
| Mar 24 12:29:53 <lsmith> ok .. then lets discuss this | |
| Mar 24 12:29:55 <Seldaek> it'll look weird for 3 days | |
| Mar 24 12:29:58 <Seldaek> then we'll be used to it | |
| Mar 24 12:30:02 <jmikola|w> wasn't kriswallsmith's aliases able to work around that? | |
| Mar 24 12:30:04 <lsmith> i agree with Seldaek | |
| Mar 24 12:30:20 <jmikola|w> or were we not going to employ that for the core config stuff | |
| Mar 24 12:30:36 * Bastor ([email protected]) has joined #symfony-dev | |
| Mar 24 12:30:37 <fabpot> I don't see the big deal about keeping the current names for core bundles | |
| Mar 24 12:30:49 <lsmith> fabpot: its about eating our own standards | |
| Mar 24 12:30:50 <henrikbjorn> i think the current names should stay | |
| Mar 24 12:31:09 <fabpot> lsmith: that's already not the case as we have a Bundle\ sub-namespace | |
| Mar 24 12:31:12 <lsmith> or at least we then should state clearly in our docs that people shouldnt look at the core bundles if they want to follow our "best practices" | |
| Mar 24 12:31:14 <jmikola|w> is essentially the same as using non-prefixed service id's elsewhere... if core stuff is going to have top-level names w/o prefixes for services, i don't see why not for configs | |
| Mar 24 12:31:15 <henrikbjorn> lsmith: they are point zero and core to the framework so they dont really belong to anyone | |
| Mar 24 12:31:50 <jmikola|w> lsmith: perhaps that best practice should start applying for something like FrameworkExtraBundle? instead of the core stuff | |
| Mar 24 12:32:02 <fabpot> jmikola|w: that's already the case | |
| Mar 24 12:32:15 <lsmith> alright then .. i will submit something a PR to add to the docs that core Bundles do not follow the best practices | |
| Mar 24 12:32:24 <jmikola|w> yes; i meant to say that's the line when we start enforcing best practices, not core bundles | |
| Mar 24 12:32:26 <everzet> :-) | |
| Mar 24 12:32:44 <lsmith> so bridges each of the maintainers will handle themselves | |
| Mar 24 12:33:00 <lsmith> missing interfaces should just be filed as tickets or PR's by the person that misses them | |
| Mar 24 12:33:29 <lsmith> "overwriting bundle parameters" .. i will submit a PR to add to the docs that people shouldnt rely on BC when overriding bundle parameters | |
| Mar 24 12:33:43 <lsmith> should i create a ticket for removing class parameters? | |
| Mar 24 12:34:03 <Seldaek> I would say no | |
| Mar 24 12:34:09 * DolbyDB ([email protected]) has joined #symfony-dev | |
| Mar 24 12:34:10 <fabpot> lsmith: that's also on my TODO list | |
| Mar 24 12:34:14 <Seldaek> they can stay there as an unsupported extension point for dirty hacks | |
| Mar 24 12:34:14 <lsmith> k | |
| Mar 24 12:34:22 <Seldaek> but nobody seems to like that :p | |
| Mar 24 12:34:41 <everzet> Seldaek: no one likes dirty hacks anymore :-( | |
| Mar 24 12:34:51 <Seldaek> yeah, that's just no fun. dirty hacks are useful sometimes. | |
| Mar 24 12:34:58 <lsmith> ok .. that covers all the topics from that list that havent been covered yet | |
| Mar 24 12:35:04 <Seldaek> everything is private and strict now.. | |
| Mar 24 12:35:05 <lsmith> so next topic .. ok? | |
| Mar 24 12:35:07 <henrikbjorn> looks like ill need to redefine a lot of services then | |
| Mar 24 12:35:08 <jmikola|w> Seldaek: we still need dirty hacks for some things :) | |
| Mar 24 12:35:09 <henrikbjorn> awesome | |
| Mar 24 12:35:13 <johanness> actually changing the class is less risky than changing the entire service | |
| Mar 24 12:35:47 <lsmith> Naming collisions with Bundles: http://bit.ly/hwgDTp, http://bit.ly/hdCVYX | |
| Mar 24 12:35:50 <lsmith> kriswallsmith: ? | |
| Mar 24 12:35:54 <Seldaek> yeah I really don't htink it's a good idea to remove those class params | |
| Mar 24 12:36:14 <everzet> Seldaek: +1 | |
| Mar 24 12:36:15 <kriswallsmith> i just stepped away, what's up? | |
| Mar 24 12:36:16 <beberlei> regarding bridges, we will create a doctrine one for form related stuff and move some stuff for twig into the twig one | |
| Mar 24 12:36:16 * jstout ([email protected]) has joined #symfony-dev | |
| Mar 24 12:36:21 * dbu has quit (Remote host closed the connection) | |
| Mar 24 12:36:27 <fabpot> beberlei: thanks | |
| Mar 24 12:36:33 <beberlei> i had a question about naming bridges that combine two components | |
| Mar 24 12:36:51 <beberlei> for example the translating helper in Framework Bundle | |
| Mar 24 12:36:54 <lsmith> kriswallsmith: just wanted to move to the topic of bundle alias's .. but it seems we are not yet ready to | |
| Mar 24 12:37:09 * jakubzalas ([email protected]) has joined #symfony-dev | |
| Mar 24 12:37:11 <beberlei> should we create a Symfony\Bridge\TemplatingTranslation ? | |
| Mar 24 12:37:16 <beberlei> or how should that be handled | |
| Mar 24 12:37:19 <kriswallsmith> i think class names should remain as parameters | |
| Mar 24 12:37:45 <lsmith> ok .. so does everybody understand the topic if class parameter removal? if so we can have a quick vote | |
| Mar 24 12:37:52 <jmikola|w> kriswallsmith: perhaps at least for public services? or privates as well | |
| Mar 24 12:38:08 <fabpot> beberlei: bridges are for third-party libraries only | |
| Mar 24 12:38:10 <henrikbjorn> -1 for removing | |
| Mar 24 12:38:18 <fabpot> -1 | |
| Mar 24 12:38:21 <everzet> -1 | |
| Mar 24 12:38:21 <avalanche123> -1 | |
| Mar 24 12:38:30 <kriswallsmith> -1 for removing | |
| Mar 24 12:38:30 * igorw_ ([email protected]) has joined #symfony-dev | |
| Mar 24 12:38:31 * igorw_ has quit (Changing host) | |
| Mar 24 12:38:31 * igorw_ (~igorw@phpbb/developer/evil3) has joined #symfony-dev | |
| Mar 24 12:38:35 <Seldaek> +1 for dirty hacks | |
| Mar 24 12:38:40 <kriswallsmith> heh | |
| Mar 24 12:38:41 <everzet> Seldaek: :-D | |
| Mar 24 12:38:49 <beberlei> fabpot: so how should we handle the translation helper? it seems to me that its wrongly placed in framework bundle | |
| Mar 24 12:38:51 <lsmith> i know bschussek was -1 (aka removing) .. i am +0 | |
| Mar 24 12:38:54 <jmikola|w> -1, unless we go all out for configs that make it easier to avoid dirty hacks | |
| Mar 24 12:39:08 <lsmith> kriswallsmith: are you sure you voted like you intended? | |
| Mar 24 12:39:08 <henrikbjorn> to be honost a lot of flexibilty is gone if class params are removed | |
| Mar 24 12:39:20 <lsmith> ah no | |
| Mar 24 12:39:23 <lsmith> i am confused | |
| Mar 24 12:39:24 * ornicar ([email protected]) has joined #symfony-dev | |
| Mar 24 12:39:28 <beberlei> i am against removal | |
| Mar 24 12:39:31 <fabpot> beberlei: I will have a look at this specific example | |
| Mar 24 12:39:31 <beberlei> if that is -1 | |
| Mar 24 12:39:35 <lsmith> so -1 is not removing the class parameters | |
| Mar 24 12:39:38 <fabpot> yes | |
| Mar 24 12:39:40 <avalanche123> yes | |
| Mar 24 12:39:41 <jmikola|w> i thought it was | |
| Mar 24 12:39:42 * johnwards ([email protected]) has joined #symfony-dev | |
| Mar 24 12:39:44 <everzet> yep | |
| Mar 24 12:39:46 <beberlei> lol | |
| Mar 24 12:39:46 <fabpot> so, basically nobody want to remove them | |
| Mar 24 12:39:48 <lsmith> ok .. so they will stay .. | |
| Mar 24 12:39:50 <avalanche123> yes | |
| Mar 24 12:39:54 <jmikola|w> great success! | |
| Mar 24 12:39:55 <lsmith> good | |
| Mar 24 12:39:58 <lsmith> now moving on | |
| Mar 24 12:39:58 <henrikbjorn> awesome | |
| Mar 24 12:39:59 <henrikbjorn> :p | |
| Mar 24 12:40:00 <avalanche123> unity | |
| Mar 24 12:40:01 <lsmith> Naming collisions with Bundles: http://bit.ly/hwgDTp, http://bit.ly/hdCVYX | |
| Mar 24 12:40:02 * igorw has quit (Ping timeout: 276 seconds) | |
| Mar 24 12:40:03 * igorw_ is now known as igorw | |
| Mar 24 12:40:05 <lsmith> kriswallsmith: take it away :) | |
| Mar 24 12:40:29 <lsmith> or fabpot .. i saw you have made up your mind | |
| Mar 24 12:40:46 <lsmith> or lets say the topic is many fold | |
| Mar 24 12:41:09 <lsmith> i think one is about in general us not enforcing namespacing of services etc in Bundles | |
| Mar 24 12:41:20 <lsmith> the other is kriswallsmith's PR about Bundle alias's | |
| Mar 24 12:41:22 * kris|m ([email protected]) has joined #symfony-dev | |
| Mar 24 12:41:58 <lsmith> imho not enforcing namespacing for services and the likes is ok .. we just have to document it as part of the best practices | |
| Mar 24 12:42:17 <fabpot> lsmith: I don't understand why we would want to enforce namespaces for services | |
| Mar 24 12:42:24 <lsmith> fabpot: neither do i | |
| Mar 24 12:42:25 <beberlei> hm, every implementator has the right to claim the default namespace for himself | |
| Mar 24 12:42:39 <beberlei> so "request", "router" as a service is very nice imho | |
| Mar 24 12:42:54 <beberlei> namespacing third party bundle services should be done though | |
| Mar 24 12:42:58 * IfSixWasNine has quit (Quit: IfSixWasNine) | |
| Mar 24 12:42:59 <beberlei> as a best practice | |
| Mar 24 12:43:06 <beberlei> am i talking on the right topic? | |
| Mar 24 12:43:08 <beberlei> :p | |
| Mar 24 12:43:12 <lsmith> beberlei: yes .. by documentation .. not by force | |
| Mar 24 12:43:24 <lsmith> so the other side of the topic is https://github.com/symfony/symfony/pull/186 | |
| Mar 24 12:43:32 <lsmith> aka "Bundle (and extension) aliases" | |
| Mar 24 12:43:39 <lsmith> which is kriswallsmith's pull .. but he seems to be afk? | |
| Mar 24 12:44:04 * kris|m has quit (Client Quit) | |
| Mar 24 12:44:15 <lsmith> from fabpot's last comment .. it sounds like either we shouldnt add the feature at all | |
| Mar 24 12:44:21 <fabpot> I'm -1 as it introduces yet another way to reference a bundle | |
| Mar 24 12:44:35 <kriswallsmith> I'm here | |
| Mar 24 12:44:46 <lsmith> or at least only offer it as a "use at your own risk" for peoples own application bundles | |
| Mar 24 12:44:51 <Seldaek> I think if it's merged, then the @-magic should go away so it's either FQCN, or alias | |
| Mar 24 12:45:06 <rande> me too ;) I will prefer to remove the 'Bundle' keyword | |
| Mar 24 12:45:12 <Seldaek> but the fact that it's defined outside of the bundle is a bit nasty | |
| Mar 24 12:45:37 <kriswallsmith> Seldaek: that's the whole point | |
| Mar 24 12:45:49 <kriswallsmith> I'm ok with closing the PR | |
| Mar 24 12:45:59 <Seldaek> of course, if we called Bundles "Zs" instead of Bundles, then it'd be easier to type BlogZ:Post:blah.html.twig | |
| Mar 24 12:46:00 * henrikbjorn has quit (Ping timeout: 276 seconds) | |
| Mar 24 12:46:06 <fabpot> rande: we can remove the Bundle suffix, that's a valid proposal | |
| Mar 24 12:46:07 <kriswallsmith> if people don't like it | |
| Mar 24 12:46:08 * henrikbjorn ([email protected]) has joined #symfony-dev | |
| Mar 24 12:46:10 <Seldaek> +1s on Zs? :/ | |
| Mar 24 12:46:12 * henrikbjorn has quit (Remote host closed the connection) | |
| Mar 24 12:46:27 <everzet> fabpot: oh. That's interesting | |
| Mar 24 12:46:34 <Seldaek> fabpot: seriously? I don't know how many times I've bitched about the Bundle suffix | |
| Mar 24 12:46:44 <Seldaek> that'd be awesome | |
| Mar 24 12:46:49 <everzet> Seldaek: +1 | |
| Mar 24 12:46:52 <avalanche123> Bundle\Bundle\BundleBundle | |
| Mar 24 12:47:19 <fabpot> avalanche123: so, you work for the Bundle company now? that's a problem for sure ;) | |
| Mar 24 12:47:23 <Seldaek> Symfony\Bundle\Framework\FrameworkBundle / Liip\View\ViewBundle | |
| Mar 24 12:47:24 <avalanche123> :) | |
| Mar 24 12:47:35 <everzet> Behat\Bundle\BehatBundle | |
| Mar 24 12:47:39 <avalanche123> fabpot, indeed, we make Bundles | |
| Mar 24 12:47:40 <Seldaek> that'd be nicer already, and especially View:Foo:bar would be much nicer | |
| Mar 24 12:47:45 <fabpot> Liip\View\ViewBundle should be Liip\View\LiipViewBundle | |
| Mar 24 12:47:52 <Seldaek> fabpot: yeah sorry | |
| Mar 24 12:47:56 <fabpot> so LiipView:For:Bar | |
| Mar 24 12:47:57 <avalanche123> oh | |
| Mar 24 12:48:02 <avalanche123> so Bundle\Bundle\BundleBundleBundle | |
| Mar 24 12:48:09 <jstout> avalanche123: haha | |
| Mar 24 12:48:42 <avalanche123> :) | |
| Mar 24 12:48:43 <lsmith> ok why didnt we change this before? | |
| Mar 24 12:48:50 <lsmith> because i remember that we talked about it | |
| Mar 24 12:49:01 <avalanche123> it wasn't that obvious I think | |
| Mar 24 12:49:05 <Seldaek> afaik, everytime I ranted, it was said that it was confusing that the directory wasn't called *Bundle | |
| Mar 24 12:49:14 <avalanche123> and it alse made sense, we have *Controller classes | |
| Mar 24 12:49:15 <everzet> lsmith: because there was no Bundle\Bundle\BundleBundleBundle | |
| Mar 24 12:49:31 <Seldaek> but on the other hand, it makes the code feel symfony specific because it is called bundle, while it's really not that specific | |
| Mar 24 12:49:36 <kriswallsmith> we can just lob Bundle off the name | |
| Mar 24 12:49:38 <Seldaek> so it's better without *Bundle imo | |
| Mar 24 12:49:47 <Seldaek> we might even argue we don't need bridges anymore ;) | |
| Mar 24 12:49:58 <kriswallsmith> no need to change the class name or ns | |
| Mar 24 12:49:59 <jmikola|w> so Bundle only goes in the namespace component, or it's completely optional? i was also afk | |
| Mar 24 12:50:14 <fabpot> Just to be clear, I propose to remove the Bundle suffix in the shortcut notation, I do not propose to rename the bundle class | |
| Mar 24 12:50:20 <everzet> I think we don't need Bundle in actual bundle name as we already have it in NS | |
| Mar 24 12:50:23 <lsmith> fabpot: ah :) | |
| Mar 24 12:50:27 <avalanche123> fabpot understood that and +1 | |
| Mar 24 12:50:30 <jmikola|w> fabpot: that certainly makes sense | |
| Mar 24 12:50:30 <beberlei> fabpot: +1 | |
| Mar 24 12:50:34 <kriswallsmith> fabpot: +1 | |
| Mar 24 12:50:36 <lsmith> thats what i also understood initially .. but people confused me | |
| Mar 24 12:50:41 <Seldaek> fabpot: ok, that's only 0.5x as awesome, but it's still a great change | |
| Mar 24 12:50:44 <Stof> fabpot: +1 | |
| Mar 24 12:50:48 <jstout> fabpot: +1 ! | |
| Mar 24 12:50:48 <lsmith> +1 | |
| Mar 24 12:50:55 <everzet> +0.5 | |
| Mar 24 12:51:01 <fabpot> ok, who wants to work on the patch? | |
| Mar 24 12:51:12 <johanness> can there be conflicts if we remove this? | |
| Mar 24 12:51:24 <Seldaek> no, bundle was mandatory afaik | |
| Mar 24 12:51:36 <jmikola|w> beberlei: when we call getRepository with something like MainBundle:User and it translates to Vendor/MainBundle/Entity/User, is that magic inside doctrine bundle? | |
| Mar 24 12:51:38 <lsmith> i volunteer Seldaek :) | |
| Mar 24 12:51:54 <Seldaek> lsmith: well, I would, but I have beer waiting for me. I can try to do it this weekend though | |
| Mar 24 12:51:57 <jmikola|w> johanness: i don't think there will be conflicts, as it's just removing "Bundle" suffix across the board | |
| Mar 24 12:52:01 <beberlei> jmikola: yes, its called Entity Namespace Alias | |
| Mar 24 12:52:06 bantu Bastor beberlei BeryWork bobthecow bshafs | |
| Mar 24 12:52:12 <kriswallsmith> I'll do the patch | |
| Mar 24 12:52:13 <jmikola|w> beberlei: and those are configured from the config mapping block? | |
| Mar 24 12:52:19 <lsmith> ok .. then last topic | |
| Mar 24 12:52:20 <lsmith> Cache warming: http://bit.ly/dIoSCc, http://bit.ly/f0yI0z | |
| Mar 24 12:52:23 <lsmith> kriswallsmith: thx! | |
| Mar 24 12:52:23 <beberlei> jmikola|w yes | |
| Mar 24 12:52:30 <lsmith> is there still something to be done where? | |
| Mar 24 12:52:38 <lsmith> s/where/there | |
| Mar 24 12:52:43 <Stof> jmikola|w: Doctrine allows to define an alias for a namespace. Then DoctrineBundle define it by default for bundles and you can change them | |
| Mar 24 12:52:48 <Seldaek> kriswallsmith: great | |
| Mar 24 12:52:59 <fabpot> lsmith: yes, I have not had time to have a look at it | |
| Mar 24 12:53:03 * chirimoya has quit (Quit: Linkinus - http://linkinus.com) | |
| Mar 24 12:53:17 <beberlei> Stof: you can change them, there is a parameter ofr it | |
| Mar 24 12:53:29 <beberlei> was it removed? | |
| Mar 24 12:53:34 <lsmith> is there someone else with sufficient deep understanding of all the issues that could discuss this with you fabpot to take it off your hands? | |
| Mar 24 12:53:35 <Stof> beberlei: I just said it | |
| Mar 24 12:53:36 <kriswallsmith> beberlei: can you update D bundles with the alias change? | |
| Mar 24 12:53:40 * tystr ([email protected]) has joined #symfony-dev | |
| Mar 24 12:53:51 <Seldaek> just one quick question if we are out of topics.. what's with the form component? should we schedule a meeting this weekend? should we all try to have a look at it? Can someone do a PoC bundle we could look at to get a feel how it works? | |
| Mar 24 12:53:52 <fabpot> lsmith: I just have a feeling, no hard facts | |
| Mar 24 12:53:53 <beberlei> just remove the *BUndle or what? | |
| Mar 24 12:53:53 <Stof> kriswallsmith: I will do that | |
| Mar 24 12:54:05 <kriswallsmith> Stof: thanks | |
| Mar 24 12:54:15 <kriswallsmith> beberlei: exactly | |
| Mar 24 12:54:35 <avalanche123> I wanted to discuss mongodb session storage and where you think it makes sense to put it | |
| Mar 24 12:54:59 <avalanche123> I have it implemented and working and we don't want to put it into http foundation | |
| Mar 24 12:55:05 <avalanche123> but it doesn't rely on doctrine | |
| Mar 24 12:55:07 <beberlei> bridge | |
| Mar 24 12:55:13 <avalanche123> and uses raw Mongo class | |
| Mar 24 12:55:26 <avalanche123> beberlei, how does it work? | |
| Mar 24 12:55:29 <jstout> I'm with Saldaek on the forms. | |
| Mar 24 12:55:48 <johanness> avalanche123, why don't you want to put it into http foundation? | |
| Mar 24 12:55:53 <fabpot> beberlei: no, it's not a bridge as their is no third-party lib | |
| Mar 24 12:56:02 <fabpot> johanness: because I don't want to | |
| Mar 24 12:56:02 <lsmith> beberlei: so the PR didnt happen today .. will it happen tomorrow? | |
| Mar 24 12:56:04 <beberlei> pecl/mongodb is sort of third party :D | |
| Mar 24 12:56:06 <johanness> :) | |
| Mar 24 12:56:07 <jmikola|w> avalanche123: is there a memcache driver in core? | |
| Mar 24 12:56:18 <avalanche123> jmikola|w, not necessary | |
| Mar 24 12:56:24 <beberlei> lsmith: bschussek will be back at 9, there are small details that need to be worked on, the PR will be tonight or tomorrow | |
| Mar 24 12:56:30 <lsmith> ok | |
| Mar 24 12:56:30 <avalanche123> you just configure memcache with session support when compiling php | |
| Mar 24 12:56:36 <avalanche123> jmikola|w ^ | |
| Mar 24 12:56:37 <mvrhov> regarding the experimental forms. Rendering is broken currently so I've converted one form class to new syntax, but got stuck there. | |
| Mar 24 12:56:40 <lsmith> so i think we need at least 24 hours to review the PR | |
| Mar 24 12:56:47 <lsmith> before it makes sense to take a decision | |
| Mar 24 12:56:48 <Seldaek> jmikola|w: it's not about core/thirdparty, it's about what we want to support in Sf-core I think | |
| Mar 24 12:56:52 * guilhermeblanco (~quassel@nat/yahoo/x-hoarhdgilokaksdg) has joined #symfony-dev | |
| Mar 24 12:57:05 <lsmith> should we do an IRC meeting to discuss the last questions and vote on the weekend? | |
| Mar 24 12:57:07 <avalanche123> Seldaek right | |
| Mar 24 12:57:09 <beberlei> there will also be an Acme Bundle on the Forms | |
| Mar 24 12:57:18 <lsmith> beberlei: great | |
| Mar 24 12:57:23 <beberlei> so that everyone can see some use.cases, i am working on that tonight | |
| Mar 24 12:57:28 <fabpot> lsmith: I will definitely need more than 24 hours | |
| Mar 24 12:57:31 <avalanche123> so beberlei, HttpFoundationMongoBridge? | |
| Mar 24 12:57:35 <jmikola|w> Seldaek: i was just considering if there was a problem conditionally supporting pecl extensions in core | |
| Mar 24 12:57:42 <lsmith> ok .. so then a meetin on monday? | |
| Mar 24 12:57:46 <Seldaek> jmikola|w: the question is, if we move it in core, can we trust avalanche123 to maintain it or will he try to make a run for the mexican border at the first occasion? | |
| Mar 24 12:57:46 <lsmith> or wait until next thursday | |
| Mar 24 12:58:04 <jmikola|w> Seldaek: Mongo doesn't really seem common enough to be in core, but i don't see harm in having the code there - it simply wouldn't get loaded if people don't use it | |
| Mar 24 12:58:05 <lsmith> or only schedule a meeting if we feel we need one | |
| Mar 24 12:58:20 <lsmith> otherwise just handle it via PR comments and mailinglist | |
| Mar 24 12:58:22 <jmikola|w> Seldaek: Bulat legally can't cross any other borders, so we're good | |
| Mar 24 12:58:27 <avalanche123> Seldaek, you can trust me ;) | |
| Mar 24 12:58:31 <fabpot> lsmith: yes, let's discuss everything on the ML | |
| Mar 24 12:58:35 <lsmith> ok | |
| Mar 24 12:58:38 <avalanche123> jmikola|w haha | |
| Mar 24 12:58:40 * henrikbjorn ([email protected]) has joined #symfony-dev | |
| Mar 24 12:58:41 <lsmith> so then meeting done |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment