IRC Meeting Week 50

log-week-50.txt

[17:22] Stof: flevour: no, that means that the code using equals will be refactored to move the logic out of the User class
[17:22] drak: hi Fabien :)
[17:22] Stof: so no method in UserInterface
[17:22] fabpot: sorry for being late, I totally forgot about the meeting
[17:22] drak: you were just in time, they were about to cancel :)
[17:23] fabpot: have you started yet?
[17:23] flevour: fabpot: lukas won't be here as per https://twitter.com/lsmith/status/147348424755396609 , but we can go through the topics he indicated anyway, what do you think?
[17:24] fabpot: yep, lzt's start
[17:24] flevour: ok, first topic is [FrameworkBundle] added ability to have async/sync render tags http://goo.gl/7bAk8
[17:24] Seldaek: kbond: ^
[17:24] kbond: here
[17:25] fabpot: I think we need to discuss this vs HInclude
[17:25] Seldaek: yup
[17:25] fabpot: and why we should add support in the core, instead of just using HInclude
[17:25] Seldaek: well, one could argue that HInclude is like ESI, we can choose to help people integrate it, or not
[17:26] Seldaek: having stuff in core usually sends a strong message
[17:26] fabpot: Seldaek: yes and no as ESI requires a lot of work on the server side. HInclude is only client-side
[17:26] fabpot: a cookbook entry about HInclude can be enough to make everybody aware of a "best-practice"
[17:26] Seldaek: well from the framework's point of view, it's kind of the same, you output a tag and some external thing fetches the content later?
[17:26] fabpot: … if we decide that this is worth it of course
[17:27] fabpot: Seldaek: not really as we have support for the PHP-based reverse proxy code
[17:27] fabpot: which is the bulk of the code actually
[17:27] Seldaek: yeah I know but that's kind of out of the framework
[17:27] kbond: if we include hinclude tags in core, it won't work out of the box unless we include the js
[17:27] Seldaek: it's great, but not directly related to easy support of ESI in code imo
[17:27] fabpot: note that I'm not against adding support for HInclude into the core
[17:28] • Crell 
has never heard of hinclude before.
[17:28] fabpot: Crell: http://www.mnot.net/javascript/hinclude/
[17:28] Seldaek: it's basically client-side ESI
[17:28] Crell: Yeah, just googled. ;-)  how does that differ from backbone.js?
[17:28] Seldaek: the main difference is that you can provide some "alternative content" that is displayed until the element is loaded
[17:28] Crell: I see.
[17:28] Seldaek: difference from ESI I mean
[17:29] Seldaek: difference with backbone well.. it's nothing like it I would say :)
[17:29] couac: why should we add this feature to the core ?
[17:29] fabpot: and Mark Nottingham is the author of both ESI and HInclude
[17:30] fabpot: couac: that's the question. Do we need code in the core or is a cookbook entry enough
[17:30] flevour: should core advice for a tecnique that speeds up rendering but multiplies HTTP requests?
[17:30] couac: a bundle is enough IMO
[17:30] Stof: couac: to make it easy for users by supporting it in the {% render %} tag instead of having a different one for HInclude (which would be necessary if it is another bundle doing the job
[17:31] Seldaek: flevour: more http requests isn't necessarily bad, as long as they're not blocking and happen after the main content loaded
[17:31] Seldaek: ESI is blocking, serverside
[17:31] kbond: for how little code it would take to add this feature to the {% render %} tag it is worth it imo
[17:31] fabpot: first, we need to agree that we don't need to reinvent the wheel as proposed in the existing PR and use HInclude instead?
[17:31] Seldaek: which can be annoying when stuff you render in ESI is really not important
[17:32] fabpot: then, if we agree that HInclude is the way to go, we need another PR to have a feeling about what "supported in the core" actually means
[17:32] Seldaek: IMO hinclude seems fine, and then it boils down to whether we can add it to the render tag or not
[17:32] Seldaek: if not, then it doesn't really have to be in core
[17:33] flevour: render tag could support a type option which can be async-js, sync-js or whatever and offer some support to attach renderers via DIC tags
[17:33] fabpot: Seldaek: agreed
[17:34] flevour: I have the feeling all those async-js: true, sync-js: true, etc would clutter render tag documentation too
[17:34] flevour: 10 mins on this topic, a few more before next one
[17:35] rande: I will update the SonataPageBundle with hinclude too!
[17:35] couac: lol
[17:35] fabpot: so, anyone willing to try the integration of HInclude into the current render tag?
[17:36] Seldaek: hopefully kbond can keep going on the issue
[17:36] rande: couac: I didn't know about it until now
[17:36] fabpot: ok, I will add a note on the PR then
[17:36] kbond: yeah i can open a new pr
[17:37] flevour: ok, let's move to the next topic then?
[17:37] flevour: [HttpKernel] Add Kernel::terminate() and HttpKernel::terminate() for post-response logic http://goo.gl/6f5ea
[17:39] flevour: lsmith: wb
[17:40] fabpot: anybody on this topic?
[17:41] ballisticpain: I think the people on this topic are travelling?
[17:41] flevour: Seldaek: maybe you?
[17:41] Seldaek: well, maybe
[17:41] Seldaek: :)
[17:41] fabpot: Seldaek: come one
[17:41] Seldaek: basically the PR is there, I think it would be good to merge it because IMO this "post-response" event is the only one missing to have events along the entire request/response flow
[17:42] phidah: I have added this annotation @Route("/admin/entity_category") to my controller and this one @Route("/", name="admin_entity_category") to the action. However if I go to /admin/entity_category no route matches… FrameworkExtraBundle is enabled… Any clues?
[17:42] Seldaek: I'm not sure what are the concerns
[17:42] fabpot: Seldaek: I'm more convinced now as more people have commented on this PR with their use cases
[17:43] Seldaek: ok
[17:43] fabpot: would it make sense to merge the Kernel shutdown and terminate methods?
[17:43] ballisticpain: phidah: Please go to the #symfony channel having a dev discussion in here currently.
[17:43] Seldaek: fabpot: I don't like it because IMO in production calling shutdown isn't really necessary
[17:43] phidah: OOps, sorry this was the wrong channel :)
[17:43] fabpot: Seldaek: right
[17:43] Seldaek: especially if many bundles start to do GC stuff to avoid problems in functio al tests
[17:44] Seldaek: so I think keeping them separated is better
[17:44] ballisticpain: phidah: No worries. :)
[17:44] fabpot: So, if nobody have concerns, I will merge the PR
[17:44] Seldaek: good, last topic then flevour ?
[17:45] flevour: [BC Break][Security] Renamed equals to isSameUser in the UserInterface http://goo.gl/78dqf
[17:45] couac: the issue there is that it seems we moved to another point of view
[17:46] couac: it's no more about renaming the `equals` method
[17:46] trompette: but a equatable interface
[17:46] couac: yep
[17:46] trompette: it has been discussed at the last meeting
[17:46] fabpot: I wasn't there during the last meeting
[17:47] trompette: the one before that maybe
[17:47] trompette: i remember you commenting on the thing
[17:49] fabpot: so, is there something we need to discuss or are we just waiting for an implementation?
[17:49] couac: nothing to say
[17:49] trompette: fabpot: are you ok with the equatable interface ?
[17:50] trompette: just to be clear
[17:50] Stof: fabpot: waiting for an implementation. Unfortunately I have been quite busy so I haven't had time to work on it
[17:50] couac: someone has to work on an impl
[17:50] fabpot: Stof: no worries
[17:50] Stof: so if someone else wants to take the job, feel free
[17:50] fabpot: trompette: AFAIU, the interface would be optional
[17:51] trompette: i meant the idea of an interface
[17:51] trompette: instead of a simple rename of the method name
[17:52] fabpot: yeah, looks good to me. But as always, I need to see some code ;)
[17:52] Stof: trompette: the idea suggested previously was not to have an interface implemented by User (as the issue with the method name would stay the same) but to move the comparison to another object
[17:52] Stof: and to provide a default implementation in Security
[17:53] jmikola|w: UserComparator?
[17:53] Stof: something like this, yes
[17:53] trompette: ok my bad
[17:56] flevour: so a UserComparator implementing a method taking 2 UserInterfaces as params and returning a boolean?
[17:56] Stof: flevour: yes
[17:56] flevour: ideas on the name of the method, while we are at it/
[17:56] couac: isn't a bit overkill ?
[17:57] flevour: 5 mins to go
[17:58] Stof: couac: some people said that deciding whether the user has changed since the latest login is not the responsibility of the User object itself
[17:59] Stof: flevour: after this topic is completed, I have a small point to add
[17:59] flevour: Stof: alright, since we had only 3 topics there's enough time to discuss one more!
[17:59] drak: :)
[17:59] flevour: :p
[17:59] drak: Sessions/flashes?
[18:00] • Crell 
perks up.
[18:00] drak: I actually thought it was already proposed (I wasnt wearing my glasses when I looked at the doodle :-P
[18:00] flevour: I would like to make sure this topic is completed. Anyone has anything to add to the whole UserComparator idea?
[18:02] flevour: Stof: there you go.
[18:02] Stof: fabpot: when will DoctrineBundle be removed from symfony/symfony ? Moving it to Doctrine has already been agreed and beberlei said the new repo is ready (he alreayd uses it in prod)
[18:02] beberlei: ah meeting
[18:02] fabpot: Stof: I'm waiting for beberlei to give me the final go
[18:02] Stof: so beberlei ?
[18:02] beberlei: hehe thats a recursion loop then, i wait for you ;)
[18:03] beberlei: from my pov its everything prepared
[18:03] beberlei: i have a blog post ready with migration details
[18:03] • Stof 
throws a CircularReferenceException :)
[18:03] trompette: ahah :)
[18:03] beberlei: i need to merge the two PRs on the migration and fixture bundle that add Doctrine namespace
[18:04] fabpot: beberlei: ok, if you have time, we can do that now
[18:04] beberlei: but that is even no problem since we have the BC repos on symfony org
[18:04] beberlei: let me check if there was a new commit
[18:05] beberlei: there have been changes in doctrine bundle
[18:06] beberlei: btw we can have the symfony doctrine bundle and the one in doctrine org side by side for some days, have everybody see the blog posts and prepare
[18:06] Stof: fabpot: is 2.0 merged into master recently to be sure all changes are in DoctrineBundle master ?
[18:06] beberlei: there was a 2.0 merge into doctrine bundle 2 days ago
[18:08] beberlei: fabpot: i have to merge those changes into doctrine bundle first, but we can start writing the blog post and announce the removal for say like next week
[18:08] fabpot: beberlei: ok
[18:08] beberlei: and then people can already move over their code to doctrine org bundle and then at some point you just delete the code
[18:09] beberlei: i am going home from work in some minutes, i will publish the blog post then and do the merges and such
[18:09] Stof: beberlei: you should merge the naemspace change in Fixtures and Migrations so that people switching to Doctrine repos have the good evrsion
[18:10] Stof: it will not break things for others if we don't merge back to the symfony BC forks
[18:10] beberlei: yes, will do that tonight
[18:10] beberlei: also jonwage jmikola|w or kris still have to renamespace the mongodb bundle, i will get to them on this