-
-
Save katbailey/8d58d47bd7a3c15de207 to your computer and use it in GitHub Desktop.
wscci transcript July 17th
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
[09:33am] Crell: We're trying to figure out how to handle request-dependent stuff in the DIC. | |
[09:33am] Crell: Can you add a 'request' service at runtime after the DIC is initialized? | |
[09:33am] Crell: Or, how does Symfony full stack do that? | |
[09:33am] igorw: yes, that is in fact what symfony does | |
[09:34am] igorw: the problem is that all services which depend on the request are also scoped to the "request" scope | |
[09:34am] Crell: That's a problem? | |
[09:34am] • Crell doesn't know how scoping works yet. | |
[09:34am] travelertt left the chat room. (Remote host closed the connection) | |
[09:35am] dbassendine: (newb question: what do you mean by DIC?) | |
[09:35am] katbailey: igorw: I've seen where the 'request' scope gets added to the container, e.g. in FrameworkBundle - but where does the 'request' service get added? Or is that an implicit thing? How do scopes relate to services? | |
[09:35am] Crell: Dependency Injection Container. | |
[09:35am] travelertt joined the chat room. | |
[09:35am] dbassendine: thanks | |
[09:36am] igorw: well, not per-se, but it can give you problems because anything depending on that service needs to be scoped request as well | |
[09:36am] GaborHojtsy joined the chat room. | |
[09:36am] effulgentsia: dbassendine: excellent tutorial on Symfony's DIC: http://symfony.com/doc/current/components/dependency_injection/index.html | |
[09:36am] igorw: so you need to make sure to isolate the stuff that depends on the request | |
[09:36am] GaborHojtsy: hey, (might not be avail for long) | |
[09:37am] dbassendine: excellent, thank you | |
[09:37am] linclark: did we ping Gabor because someone else had a question for him? because if not, I do | |
[09:37am] Crell: GaborHojtsy: We had language questions for you! katbailey? | |
[09:38am] effulgentsia: GaborHojtsy: A bunch of failures in http://drupal.org/node/1599108#comment-6233032 related to path and language resolution being entangled. I don't know if katbailey had a specific q though. | |
[09:38am] Druplicon: http://drupal.org/node/1599108 => Allow modules to register services and subscriber services (events) => Drupal core, base system, major, needs work, 77 comments, 20 IRC mentions | |
[09:38am] Crell: igorw: Ah, so scoping is manually specified when you register a service? It's not derived from knowing what the dependencies are? | |
[09:38am] katbailey: GaborHojtsy: well, we had been talking about language negotiation and path resolution, but I'm not sure that I had quite formulated a clear question about it yet | |
[09:38am] stkrzysiak joined the chat room. | |
[09:39am] katbailey: GaborHojtsy: if you're around on Thursday I will probably have lots of questions then | |
[09:39am] linclark: GaborHojtsy: I do have a question for you now | |
[09:39am] dbu joined the chat room. | |
[09:39am] dbu left the chat room. (*.net *.split) | |
[09:39am] forest left the chat room. (*.net *.split) | |
[09:39am] mundanity left the chat room. (*.net *.split) | |
[09:39am] DaveIngram left the chat room. (*.net *.split) | |
[09:39am] catch left the chat room. (*.net *.split) | |
[09:39am] GaborHojtsy: katbailey: I should be yes | |
[09:39am] GaborHojtsy: katbailey: generally on Thu, no specific time | |
[09:39am] linclark: so fago said something in the Format thread... http://groups.drupal.org/node/237443#comment-775863 | |
[09:40am] Druplicon: http://groups.drupal.org/node/237443 => WSCCI Web Services Format Sprint Report => 25 comments, 4 IRC mentions | |
[09:40am] katbailey: GaborHojtsy: great | |
[09:40am] travelertt left the chat room. (Ping timeout: 265 seconds) | |
[09:40am] katbailey: igorw: can you point me to the symfony code where the 'request' service gets added to the DIC, because I somehow missed that | |
[09:40am] Haza` is now known as Haza`Aw. | |
[09:40am] linclark: that we need to be able to have different term references based on language | |
[09:40am] effulgentsia: Crell: that's what I understand from http://symfony.com/doc/current/cookbook/service_container/scopes.html too. But, ContainerBuilder::compile() at least throws an exception if a wider scoped service depends on a narrower one. | |
[09:40am] GaborHojtsy: linclark: which is already possible since term is a field and fields can vary by language | |
[09:41am] linclark: GaborHojtsy: right. this is posing a problem for the serialization | |
[09:41am] linclark: GaborHojtsy: I have a diagram, http://lin-clark.com/sites/default/files/wscci_multilingual-field-model.pdf | |
[09:41am] igorw: katbailey: the scope is defined here: https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/FrameworkBundle.php#L52 the framework enters the scope here: https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/HttpKernel.php#L46 | |
[09:41am] katbailey: effulgentsia: yeah, working from that last night I had tried to create a language_manager service that had a scope of 'request' - it blew up when I tried to get it from the container | |
[09:42am] linclark: GaborHojtsy: as fago said in his post, right now you would have a field:en and a field:de value, which would contain different arrays | |
[09:42am] katbailey: igorw: aha! that second bit is what I was missing - thanks | |
[09:43am] stkrzysiak left the chat room. (Ping timeout: 248 seconds) | |
[09:43am] Crell: katbailey: So I wonder if we need to extend HttpKernel again the way FrameworkBundle does... | |
[09:43am] Crell: Since we're going to need the request scope stuff for SCOTCH, I expect. | |
[09:43am] katbailey: Crell: yeah, for subrequests I guess | |
[09:43am] Crell: Or, hell, just steal FrameworkBundle wholesale. | |
[09:43am] linclark: GaborHojtsy: would it make sense enough if all entity reference fields contained the same array, and the language variants were just taken from their values? | |
[09:44am] GaborHojtsy: linclark: well, the translation of the term and the variance of the term reference are two different concepts | |
[09:44am] GaborHojtsy: linclark: the "proposed solution" is when you make the term reference to not vary by language, which is a configuration option already in D7 | |
[09:44am] linclark: GaborHojtsy: so we definitely want to allow for variance in term reference? Like I could put completely different tags on the English version and the German version | |
[09:44am] GaborHojtsy: linclark: in that case, all language versions of the entity relate to the same set of terms | |
[09:45am] GaborHojtsy: linclark: yeah, it depends on your use case, eg. if you have term access control and you tie access to different languages by terms let's say | |
[09:45am] igorw: Crell: there are two ways to get the request into a service. either you set the scope to be "request" explicitly, then you can inject it normally via @request. the other way to do it is to use a listener, which is stateless and thus does not need to be in the request scope | |
[09:46am] GaborHojtsy: linclark: in my experience its hard to enforce multilingual sites to have a 1-1 relationship of their data in all languages | |
[09:46am] Crell: A listener where? On service instantiatio? | |
[09:46am] GaborHojtsy: linclark: not all tags might apply to all languages, etc. | |
[09:46am] Crell: instantiation? | |
[09:46am] igorw: Crell: you would make your service listen to (for example) the kernel.request event | |
[09:47am] igorw: it really depends what you need to do | |
[09:47am] linclark: GaborHojtsy, Crell: ok, if we want to allow the data model to differ between languages, then we should probably use named graphs | |
[09:47am] igorw: if you need to do something once for every request, you can use a listener | |
[09:47am] GaborHojtsy: linclark: so the language in the relation makes it possible to have different sets of terms related, the language in the term is for translating the same term | |
[09:47am] Adagio left the chat room. (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) | |
[09:47am] exlin left the chat room. (Quit: Computer has gone to sleep.) | |
[09:47am] igorw: if you need a reference to the request, and check that over and over again, you'll need a scoped service | |
[09:47am] GaborHojtsy: linclark: this applies to any entity relation, since the referenced entity can have languages on its own while the reference itself can be language dependent | |
[09:48am] igorw: in the former case, the event dispatcher creates the service when it dispatches the event | |
[09:48am] GaborHojtsy: linclark: eg. if the node author would be implemented as a user refence, I'd want to have different authors for different language versions to keep track of translators | |
[09:48am] Crell: Ah, OK. Yeah, I'm thinking of services like the object that determines what language we're currently using (which is what GaborHojtsy is discussing right now). | |
[09:48am] GaborHojtsy: linclark: its not the same guy with profiles in different languages, its separate people | |
[09:48am] igorw: to clarify, by service I mean any object managed by the DIC | |
[09:49am] Crell: Right. | |
[09:49am] linclark: then if we go with JSON-LD, we should really use named graphs | |
[09:49am] linclark: because very few people understand then | |
[09:49am] Crell: (Remember, none of us in this room have actually built a site with Symfony, so we're still learning, albeit quickly. <g>) | |
[09:49am] effulgentsia: Crell, igorw: sounds like we need a request service and a language service that depends on the request service. | |
[09:49am] linclark: GaborHojtsy: thanks for explaining the use case | |
[09:49am] Crell: effulgentsia: That's what I'm thinking, yes. | |
[09:50am] Crell: And the request service is populated at runtime by the kernel (or similar). | |
[09:50am] Crell: The language service then makes use of it whenever it gets called. | |
[09:50am] Crell: And it can pull stuff off of the request attributes that are put there by listeners that we've already implemented. | |
[09:51am] EclipseGc: effulgentsia: the request shouldn't be a service if I recall anything from what fabpot has said to me | |
[09:51am] Crell: EclipseGc: The request is a service in Symfony full stack. | |
[09:51am] EclipseGc: Crell: then it's being injected with a get from globals override in the dic? | |
[09:52am] EclipseGc: Crell: that's the only way I see it working | |
[09:52am] igorw: it's a special service because it is set at runtime and re-defined for each subrequest | |
[09:52am] EclipseGc: err… fallback, not override | |
[09:52am] effulgentsia: If I understand compilation right, the language service definition must be static, not runtime. But if scoped to request and receiving request as a constructor arg, then it will get reinstantiated whenever the request changes | |
[09:52am] GaborHojtsy: linclark: sure | |
[09:52am] Crell: EclipseGc: See the links igorw posted above. | |
[09:52am] GaborHojtsy: anything else that I can specifically help with? | |
[09:52am] effulgentsia: igorw: is that right? | |
[09:52am] Crell: HttpKernel sets it at runtime. | |
[09:52am] igorw: in fact, in the FrameworkBundle's services.xml it is defined as a "synthetic" service | |
[09:53am] Crell: synthetic? | |
[09:53am] • Crell starts to wonder if we shouldn't have just gone with full stack in the first place! | |
[09:53am] igorw: synthetic just means that no compile-time checks happen on it | |
[09:53am] EclipseGc: Crell: that's great, none of those are the actual service definition of the request though | |
[09:53am] EclipseGc: Crell: which is what I'm questioning | |
[09:53am] Crell: ? | |
[09:54am] igorw: so that you can compile the container with services depending on this synthetic request service, and after compilation set the actual service | |
EclipseGc: igorw: wait what? | |
[09:55am] igorw: effulgentsia: yes, when leaveScope gets called, all services defined in said scope are removed | |
[09:55am] EclipseGc: igorw: you can modify a compiled DIC? | |
[09:55am] wamilton_ joined the chat room. | |
[09:56am] igorw: and when enterScope is called, said services can be created again, if requested | |
[09:56am] Crell: igorw: So at compile time we define "there will be a request service here, but there isn't yet, just trust me on this". Then other things that depend on it don't break. | |
[09:56am] igorw: see FrameworkBundle's HttpKernel::handle() | |
[09:56am] Crell: And then at runtime we actually pass in the instantiated object there, and all is right with with the world. | |
[09:56am] igorw: and yes, the container can be modified after compilation | |
[09:56am] igorw: correct | |
[09:57am] wamilton left the chat room. (Ping timeout: 244 seconds) | |
[09:57am] mundanity joined the chat room. | |
[09:57am] DaveIngram joined the chat room. | |
[09:57am] catch joined the chat room. | |
[09:57am] forest joined the chat room. | |
[09:57am] effulgentsia: EclipseGc: ContainerInterface has a set() method, so looks like you can add service instances at runtime, you just can't add or change definitions | |
[09:57am] Crell: katbailey: Does that clarify things for you at all? | |
[09:57am] EclipseGc: effulgentsia: ok, so I can't add new stuff to a compiled DIC | |
[09:58am] EclipseGc: but I can change existing stuff | |
[09:58am] katbailey: Crell: absolutely! with regard to scope and the request service anyway | |
[09:58am] effulgentsia: EclipseGc: you can't add new definitions. but if you have a placeholder definition marked as synthetic, then you can set its instance at runtime | |
EclipseGc: effulgentsia: yeah ok, that answers the question enough, but I'm still not sure about request specifically, cause that seems like the sort of thing we should inject with a fallback to globals | |
[09:59am] igorw: there's some docs on container compilation btw: http://symfony.com/doc/current/components/dependency_injection/compilation.html |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment