Cекта свидетелей веб программирования

ну не совсем ты сам с помощью entries определяешь что тебе нужно доставать через container->get если для entries нужен параметр (например dsn) библиотека не может его взять с потолка значение нужно передать а где ты его хранишь в массиве, в json или yaml или xml файле это особенность твоего проекта библиотека не навязывает тебе решение, делай как хочешь но библиотеке передай одним параметром, а какой тип сюда лучше подходит ? (array) если тебе надо много таких entries и для их конфигурации надо много параметров ну значит передавай их все библиотека убедится на этапе компиляции что каждый entries достижим и в runtime не будет сюрпризов если что то забыл, библиотека не скопилирует контейнер и покажет что и где она не смогла разрешить. список entries тоже может формироваться не в ручную, а с помощью discovery но его надо реализовывать самому проекту, не библиотеки

Тогда возможно нужно показать как это делать рекомендуется. Возможно с примером symfony/config + твой контейнер

<?php namespace App; class Project extends \Cekta\DI\AbstractProject { public function __construct(public readonly array $env = getenv()) { parent::__construct( filename: __DIR__ . '/../runtime/Container.php', fqcn: 'App\Runtime\Container', params: [ // ваши параметры \PDO::class . '$dsn' => $env['DB_DSN'] ?? 'sqlite:' . __DIR__ . '/../mydb.sqlite', ], ); } public function definition(): array { return [ 'entries' => [ \PDO::class, ], 'alias' => [], 'singletons' => [], 'factories' => [], ]; } } Тут юз $env только как $env['DB_DSN'] аля опракинули снаружи. Ты хочешь сказать, что то, что передаётся в обычном symfony проекте в конфигурационных файлах/ресурсах, которых может быть туева хуча, то - что резолвится не всегда очевидным образом (компилируется и тд) и может иметь компонентную/изолированную структуру (когда одно - ничего не знает о другом) ... вот это вот всё я должен собрать и как-то передать в Project ... И при этом нет примеров как тут быть. Ну не знаю, в общем случае это выглядит проблемой. За казалось бы простой строчкой "Создаем конфигурацию вашего проекта" кроется громадное количество вопросов. Как хранить, как загружать, резолвить, передавать 😄 Ну понятно в целом. Нужно передавать. Как и что зависит от проекта. Как вам удобно так и делайте. Погуглите как конкретно вам будет лучше. Либа не может этого знать )

Я про аля такой пример (ИИ-шный код на коленке с моей мыслью) нужен там фрейм или не нужен ... просто если либа зависит от "в проекте работа с конфигами решена", то в случае если нет - помочь решить. К самой либе конечно это не относится.

насчет бутстрапа и генерации контейнера в рантайме опция такая есть но на практике она крайне не рекомендуема

🔨 1 new commit to di:documentation: 8cc616f: documentation iteration 1 by Evgeniy Kuvshinov

🔌 New pull request di#185 documentation iteration 1 by: @smpl Reply to this message to post a comment on GitHub.

🔨 2 new commits to di:master: 8cc616f: documentation iteration 1 by Evgeniy Kuvshinov 0612a6c: documentation iteration 1 (#185) by Evgeniy Kuvshinov

Узнал интересный способ как можно стандартные функции мокать в автотестах такой синтаксис доступен с php 8.1 (странно что я это не использовал раньше, приходилось через интерфейсы или классы обертки мокать) /** * @var Closure(string $filename): bool */ private readonly Closure $fileExists; /** * @var Closure(string $filename, mixed $data, int $flags =, ?resource $context =): int|false */ private readonly Closure $filePutContents; public function __construct( ?Closure $fileExists = null, ?Closure $filePutContents = null, ) { $this->fileExists = $fileExists ?? file_exists(...); $this->filePutContents = $filePutContents ?? file_put_contents(...); } до php 8.1 можно было через callable делать $this->fileExists = 'file_exists'; если это callable вызовится а с php 8.5 синтаксис стал еще проеще /** * @param Closure(string $filename): bool $fileExists */ public function __construct( private readonly Closure $fileExists = file_exists(...), ) { } кто не знал пользуйтесь по умолчанию используется обычная функция но в автотестах ее можно легко мокнуть!!! раньше для такого создавали интерфейс (и реализацию с проксированием в функцию).

на днях zed ide подружил с xdebug все оказалось довольно просто и приятно :) все это в docker

php + xdebug в docker zed ide на хосте запущенна хотя у zed ide есть интересная фишка remote ide которая очень круто отличаются от jetbrains :)

тут пришлось запустить gitlab по работе базовый образ (image) прямо включает в себе лучшие практики работы с docker postgresql['enable'] = false redis['enable'] = false nginx['enable'] = false prometheus['enable'] = false grafana['enable'] = false alertmanager['enable'] = false node_exporter['enable'] = false все свое ношу с собой, это не считая что там вмуровано puma и sidekiq

а еще gitlab CE не поддерживает логирование в stdout/stderr ну логично если оно в image как в vm сложило все что можно сколько там конфигов править надо.

а еще jira это стандарт де факто как тасктреккер но насколько на него больно смотреть когда он голый (без плагинов) там все тормозит, даже доска при изменениях не обновляется у других!!! (если кто то задачу перенес в другой статус) как такое стандарт де факто, надо свой таск треккер поэтому все фронтендеры при написание нового фреймворка рассматривали его на примере таск треккера

выплакался немного