wscci transcript July 17th

wscci_jul17.txt

[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