Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Handlers set using DrupalContextInterface::registerHandler() are basically represented by a class name and a set of params. I'd be pretty smart, IMHO that some handlers can be set as already being instanciated objects instead of a class name and a set of parameters.
Stuff such as user, language, path and other low level would have (IMHO) no gain at all not to be spawed directly since the data they will transport is almost less heavy than the class name string itself. Maybe not user, but maybe yes especially if user handler must interrogate the session handler to lazzy load the user.
Comments
Comment #1
Crell commentedI would actually argue that the really low level ones are the ones we would want lazy-instantiated the most, since we want those stored in the Config API on disk. (We're not doing that yet since Config API isn't in core yet, but it's on the todo list.) We can't store an instantiated object, but we can store the setup instructions for one. That way we have to execute almost no code to have those ready and waiting for us. And if a given request happens to never actually need a user or session (could happen, for web services), great, we never actually do that setup.
Comment #2
pounardYes true, that was more to have some example. But still makes sense to me that some modules might want to add already instanciated handlers.
Comment #3
Crell commentedIn general I agree that passing in objects is better than passing in classes. However, I'm concerned about having too many code paths if we do that, since we have to support classes anyway.
Comment #4
pounardIf you are worrying about having many code path, there is a simple solution to make this clear:
1. Create a new method
registerHandlerInfo()for the actual way of registering handlers.2. Use the legacy method
registerHandler()for registering objects.3. Move the code that spawns the handlers using the info array into a new method
createHandlerByInfo()to remove the multiple code pathes from the main offsetGet() method to its own.This creates some new methods, but it clarify the design, encapsulate this particular bit of complexity, and make the API more explicit.
This is a suggestion, any other solution might fit here.
Comment #5
webchickPer catch, and blessed by Larry, moving this and all other WSCCI issues to the Drupal core queue.
Comment #6
Crell commentedDeprecated by the new Symfony-based approach.