Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA No apologies needed. It is a personal project, but I am keen to get it right.
It initially started from a tutorial, but as you can see from the following file structures, mine on the right, I didn’t stick to the brief. It has been a fun exercise and I’ve learnt a lot in the process.
Anyway back to the task in hand.
It does feel like a lot of creating and passing viewers around unnecessarily. Could it not pass the class name or something?
I am doing a bit research into it. Last night I was reading up on the registry pattern, but I think that might be more use for making my Session class available to the views e.g.
<div> e($session->getMessage('message'))</div>
As mentioned Claude had discussed doing these setup bindings in the container.
Just having a quick peek at laravels container Container.php
I asked Claude to step back and look at the overall architecture. I felt the suggested solutions were just sticking plasters. I asked how do Symphony or Laravel handle this situation.
This is quite long text, but this was the feedback
Stepping back, I think there are two genuinely separate concerns that have been tangled into one, and that tangling is why every fix has felt like a patch rather than a solution.
…
Concern 2: every controller repeating Response $response, ViewerInterface $viewer in its own constructor.
This is the bigger smell, and it’s what’s actually driving the ErrorController-vs-Dispatcher ordering problem. Right now, any framework-wide thing a controller needs has to be re-declared, by hand, in every single controller’s constructor — and if you forget one (like HomeController did), you get an uninitialized-property crash. That’s not really a DI failure, it’s a missing piece of the DI container: a way to say “whenever anything that is a Controller gets built, regardless of who asked for it, also wire these framework services onto it.”
Tried-and-tested containers have exactly this hook. Laravel’s container has resolving()/afterResolving() — register a callback once, and it fires after every resolution of a given class/interface, no matter which code path triggered it (a normal controller dispatch, an error handler resolving ErrorController directly, a test, a console command). Symfony’s service definitions support a calls: list for the same purpose — setter injection applied uniformly by the container itself, not by whichever call site happens to remember to do it.
That’s the piece your Container (src/Framework/Container.php) doesn’t have yet. Right now the only place setter-style wiring can happen is Dispatcher::dispatch(), which is exactly why ErrorController — resolved by ErrorHandler, independent of Dispatcher — fell through the cracks. If Container::resolve() itself supported “after building an instance of X, run this callback on it,” you’d register one rule (e.g. “anything that’s a Controller gets setResponse/setViewer called on it”) in Services.php, and it would apply identically whether the controller came from Dispatcher, ErrorHandler, or anywhere else you resolve one from in the future. No more duplicating Response/ViewerInterface in every controller’s own constructor at all — those stay purely for each controller’s actual business dependencies (Listings, ListingsFormRequest, HttpErrorMessages).
That’s the structural fix I’d point you at: a small resolving(string $type, callable $callback) hook on Container, used once, rather than another round of patching individual controllers or Dispatcher. Worth having a go at designing that hook yourself — it’s a nice small piece of container design in its own right.
I’m looking at the laravel hooks options, which as far as I gather is an Observer pattern of sorts
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | splitstack/invariants | 0 | 24.29 | 03-08-2026 |
| 2 | EIP Editing Office Hour (EIP + ERC ) Meeting #108, July 28, 2026 | 0 | 18.32 | 27-07-2026 |
| 3 | Comment on resolve_pattern_blocks() by Rodrigo Vieira Eufrasio da Silva | 0 | 10.65 | 14-08-2026 |
| 4 | Rearchitecting for Drupal 8; a DrupalCon Session | 0 | 9.58 | 15-02-2018 |
| 5 | Blog: gRPC-Rust Client API Evolution (pt. 1/2) | 0 | 11.54 | 29-05-2026 |
| 6 | “Scrum didn’t work for us.” | 0 | 8.1 | 30-07-2026 |
| 7 | Trivial anti-crawler with Caddy | 0 | 8.42 | 23-06-2026 |
| 8 | Вайбкодю, потихоньку | 0 | 5 | 02-07-2026 |
| 9 | Incremental Delivery and the Need for Speed | 0 | 15.1 | 14-07-2026 |
| 10 | How should I handle daily puzzle resets across different timezones in PHP? | 0 | 10.16 | 23-09-2026 |