Posted by Crell on December 6, 2011 at 6:21am
Start:
2011-12-06 12:00 - 13:00 America/New_York Organizers:
Event type:
Online meeting (eg. IRC meeting)
It's time for another pow-wow on WSCCI! This week the main topic will be the ongoing reviews and discussions of the Context API. There's been a lot of discussion lately, and I want us to take a moment to consider the feedback to date and see what our next steps are/should be.
If you haven't read the discussion there, please do so before the meeting so we are all on the same page!
| Attachment | Size |
|---|---|
| log-2011-12-06.txt | 24.98 KB |
Comments
Status Meeting Summary
IRC Meeting 12/6/11 - 12:00 EST / 11:00 CST
Recorded on macirssi in CST TimeZone
Active participants included:
Crell, hejrocker, aspilicions, OSInet, neclimdul, lsmith, pounard,
With lurking by alexfisher, kvanderw, & chx
and a guest appearance by msonnabaum
The basis for the conversation was to discuss the concept that WSCCI Shot #1 was being over-engineered. It was initiated by Crell in response to comments on http://drupal.org/node/1233232 to that effect.
Neither catch nor beejeebus were able to make the discussion.
In an effort to bring everyone back on topic after a bit, aspilicious reduced the problem statements to:
1) some devs think it’s over engineered
2) others think the syntax is too verbose
3) others are concerned about discoverability.
In an effort to determine if this might be over-engineered, Crell has agreed to do an implementation using Pimple as an experimental alternative and then to report back on it in about a week.
Crell had already capitulated to #2 in the thread as it doesn’t seem to be an issue either way, and can be easily refactored later.
Item #3 was not touched on to any degree of discussion or agreement.
Side (non) Issues
* DIC
* rename Pimple -> Clearasil
* rename controller -> Business Manager
* Druplicon and pounard got into a fight
* DIE FAPI!!! DIE!!!
Various Links During discussion
http://en.wikipedia.org/wiki/Dependency_injection
http://fabien.potencier.org/article/11/what-is-dependency-injection
http://drupal.org/sandbox/pounard/1360694
http://drupal.org/node/1233232
See IRC log details here
Kurt Vanderwater
Drupal made Easy
Neither catch nor beejeebus
Just a note that these meetings start at 2am in my timezone (and I think even further into the middle of the night for beejeebus), so it is very unlikely that either of us will be able to attend them. I attended one wscci meeting a couple of months ago, but that was before the US went on daylight savings when they started at the more reasonable time of 1am...
Time change
I don't know if I could push it earlier given my own schedule, as I have a bunch of 10 am CST meetings setup. Were it possible, however, would you be able/willing/interested in attending more often? Or would it have to get pushed back to the point that the Americans are all still asleep, especially me? (No promise that we could change it, but should we even consider it?)
Just read through the
Just read through the backscroll. This stuck out:
11:45 <@Crell> Wouldn’t that make the http handler much more difficult?11:46 < pounard> even if that means to have other objects set behind, like, context->get(‘http_handler’)->getParam(‘q’);
11:46 < pounard> in my mind having the http handler in the context itself is weird
This seems considerably more self-documenting than the colons to me and is somewhat where my concerns with discoverability regarding the colon syntax have been trying to point towards, although not as far as this but it's been in the back of my head.
It might have other problems, but since we're not going to support $context->get('node:nid'); or $context->get('node:user:uid'); (to access properties of objects that are an actual context key), I'm not sure those are insurmountable at all. Is the issue that you would have to mock the http handler itself rather than just a value (for example to override q)?
In part, yes
I don't believe it's possible to override just one part of the request object without creating a new one. (I'm not 100% certain of that right now, but it's 12:30 am and I'm not going to go double check at the moment.)
To be fair, the colon syntax was developed before we decided to adopt HttpFoundation so at the time there was no request object to speak of, certainly not one such as we now have available. Also, not everything on the request object now maps 1:1 to something useful to Drupal. We are bypassing its language handling, for instance, and reading the data right out of the raw request due to differences in the way Drupal and Symfony2 interpret the competing standards for how language strings should be formatted. (cf, http://xkcd.com/927/)
The colon syntax unifies the set and get syntax, and hides the override logic cleanly. That may not be relevant to all keys, but does matter to the Http request, to pagers (which have many components in different key spaces), etc. (There's probably others that would need to use parameters like that, but as I said, 12:30 am.)
The colon syntax unifies the
Well it looks like there's a dichotomy between hiding the override logic, and discoverability of the system as a whole. Why do we need to hide the override logic so much?
Also I'm not sure it necessarily makes everything more unified, since getValue() can return anything the handler says it does.
If I add a 'node' handler at position 'node', then $context->getValue('node'); gets me a node object with properties (or entity object with methods).
Currently the http handler uses 'http' as a namespace, and the values of the various parts of the request are in http:foo etc.
I can't do $http = context->getValue('http'); then start using the request object API directly. On the other hand neither can I do $context->getValue('node:type');
Where's the boundary between registering a value or handler at a location in the context tree, vs. returning a class with it's own getters?
thanks for the simplification attempt
just wanted to say thanks for taking the time to try a simplified approach.
i'm totally open to being completely wrong here, and will definitely review and help where i can.
as to the meetings - yeah, its at a nasty time for me, but i'm just about the only one involved in this time zone, so don't change it. i think it would make it harder for a much broader range of people to make the meetings, and i'm happy to catch people in IRC and comment/review in the issue queues.
Same here with the meeting
Same here with the meeting time. I generally don't have much crossover with central US/west coast so if people from those times are attending you might want to leave it as is, and general irc/issues is fine.
Interesting !
@Crell, I actually read the log, looks like very interesting. After a few weeks of digesting the wscci code and principles I'll try to be more helpful. Is there any place where we can see the WIP of Pimple's implementation ?
Not yet
Pimple itself is on GitHub. Strictly speaking we don't have to use it but I figure it's small enough that we might as well for a "context junior" implementation. When I start writing code for that (I haven't yet) it will be in the WSCCI sandbox in a new branch.
I have a name for Pimple
Heyrocker proposed Clearasil. But it's a trademark. How about Pimpal ( = Pimple + Drupal) ? :)
More links
Pimple DPI:
http://pimple.sensiolabs.org/
Symfony2 DPI:
http://symfony.com/doc/current/book/service_container.html
Where Pimple stands in relation to Symfony DPI components:
http://stackoverflow.com/questions/7690973/sensiolabs-symfony-duplicated...
Thanks both of you. Pimple's
Thanks both of you. Pimple's simplicity might be a good thing, going bottom up. It may help people like me be more helpful about the code.