В Social тоже есть абстрактная реализация Oauth, так что добавлять новые провайдеры также тривиально. Я изначально думал его прикрутить, но мне не очень понравился код плюс я хотел чтобы был стандартный сериализирумый клас токена, чтобы было легко сохранять их в базе и потом строить из них клас юзера. С hybridauth пришлось бы все равно это руками прописывать.
Ну у меня тут явно комплексный вариант, как хочешь так и используй, хоть как и статический локатор. Автоваиринг еще не нравится тем что можно инжекнуть как я писал в начале статьи: совсем далекое из совсем другого концы системы. Именно поэтому у меня фабрики, каждой доступно только то к чему у нее есть доступ, то есть нельзя так просто взять и всунуть в класс валидации какой-то сервис с другого бандла. Как по мне тогда нарушается модулярность кода. То есть если вот у меня есть ОРМкак то только ее или ее репозитории можно куда-то инжектить, а не какой-то внутренний ее сервис.
Если делать автоваиринг, то ваш разработчик может смело получить доступ к сервису, к которому скорее всего ему совсем не нужно обращаться. И как раз фабрики позволяют лучше это организовать.
На самом деле во всех своих проектах я использую фабрики, так что мне все равно приходится руками описывать как строить контроллеры. Автоваиринг конечно удобно, но тогда надо еще рефлексию парсить и как-то кешировать метаданные. Если будете использовать ->instance() метод, то это только одна строчка конфигурации на контроллер, что не так уж и много, чтобы ради этого тянуть парсер и кеш. К тому же этот кеш еще надо читать и парсить на каждом запросе, а такой контейнер как в PHPixie DI закешируеться самим opcache PHP.
Но как я писал, все это дело вкуса, это лишь еще одна альтернатива. И поскольку он опциональный, то вы смело можете использовать любой другой DI компонент с PHPixie фреймворком.
он то как раз слишком много умеет, ему нужен кеш, он допускает возможность создавать новый инстанс сервисов через make(), в то время как в пикси это конфигурация решает будет ли возвращаться новый инстанс. Сам по себе PHPixie DI более строгий. Как я уже писал в другом комменте, выбор контейнера дело вкуса, этот DI достаточно отличается от других чтобы не быть клоном, а уже каким пользоваться зависит только от того какой стиль конфигурации и интерфейса вам больше нравится.
В PHPixie DI и так все работает как lazy в Aura, даже ->instance(). А вот авто разруливание сомнительная фича имхо, к тому же в случае если конструкторы принимвют интерфейсы, то настараивать какой сервис использовать вместо интерфейса все равно надо вручную. К тому же аура использует подход с ArrayAccess как и Pimpl.
На самом деле все это дело вкуса, так как самое важное это насколько вам нравится работа с контйнером. Я думаю phpixie di достаточно отличается своим интерфейсом от других чтобы не быть велосипедом, а вот какой интерфейс работы нравится больше уже решать вам.
> А почему не на примере symfony/dependency-injection?
как я писал в самом начале статьи, совсем не люблю конфигурацию зависимостей в конфиг файлах, а настройка его через PHP более громоздка, e.g.:
$container
->register('newsletter_manager', 'NewsletterManager')
->addArgument(new Reference('mailer'));
// вместо
$this->instance('newsletter_manager', NesletterManager::class, ['@mailer']);
> Поясните, что вы конкретно имеете ввиду, используя устоявшуюся терминологию.
Настраивать PHPixie DI можно только изнутри самого класса во время создания екземпляра через protected методы. То нельзя просто так взять и добавить новое значение где-то потом в рантайме, как с Pimple:
// может случится где угодно
$container['session_storage'] = function ($c) {
return new SessionStorage('SESSION_ID');
};
> Это ухудшает взаимодействие и опускает DI до уровня Service Locator или синглтонофасадов Laravel.
Как я уже писал вначале статьи, я считаю что контейнеры сильно проигрывают стандартным классам фабрик, и этот компонент написан на случай «если кому-то очень хочется контейнер». Если разработчик сам вправе решать использовать контейнер или нет, он также должен иметь право использовать синглофасады если захочет. Конечно же никто не мешает просто их не использовать если не хочется.
Я не спорю конечно что компонент симфони в совсем другой лиге. PHPixie DI больше создает конкуренцию легковесным контейнерам типа Пимпл и Аура
1) Объясню на примере Pimple, поскольку он довольно популярный:
Интерфейс ArrayAccess, прост в использование но выглядит криво в ООПшном коде.
Настраивается извне, что как я уже писал выше мне не нравится. Я хочу чтобы контейнер инкапсулировал свою логику
Нет статического интерфейса. Как по мне, кому-то то это тоже понадобится
Нет доступа к глубоким значением по точке, что выглядит не так красиво как с ней
Поскольку для вложенности надо создавать несколько контейнеров, то в случае если сервиса нет, вы получите только имя последнего ключа (например просто repository) вместо полного (user.repository).
Нет аналога $this->instance()
Если сдается примитивным, пишите которые фичи вам надо, может и появляться =)
2. Я всегда сначала пишу статью на хабр, смотрю фидбек, перевожу на англ и тогда уже ставлю в доку. Так что статья это бета тест доков ))
3. Спасибо, на самом деле у меня PHPStorm, но вот как раз эту либу писал в Атоме
Хз почему все так завелись за репутацию кстати.
На твиттере от меня никто не отписался, никто не зашел в чат и не сказал «все, завтра переписываю», даже звездочек на гитхабе на 2 больше стало. То есть, единственные кто бушует то те кто и так его не использовал ))) Это типа как феминистки против игр выступают, которые они бы и так не купили )))
С типом конечно история жесть, но напомню еще раз что я первый в треде FIG спалил что это не чисто.
Этот индекс все равно медленнее числовых, к тому же при поиске вверх (найти всех родителей) уже не помогает. Да и при собирании объектного дерева из таких записей приходится на каждой делать explode() а это тоже не дешево в большых количествах
он хорош, но только для деревьев которые не особо глубоки, а то все эти опереции с префиксами на стрингах начинают сильно тормозить. Правда как бонус путь можно сразу использовать для постройки УРЛов в рутере =)
С того что я вижу, они сохраняют значение root но не делают отдельный отсчет left и right в поддеревьях. При вставке все равно приходится сдвигать все элементы правее от новой ноды. То есть для оптимизации оно не используется и несет разве что удобство при написании запросов:
//получить все дети поддерева 1
$query = $entityManager
->createQueryBuilder()
->select('node')
->from('Entity\Category', 'node')
->where('node.root = 1')
->getQuery();
Если делать автоваиринг, то ваш разработчик может смело получить доступ к сервису, к которому скорее всего ему совсем не нужно обращаться. И как раз фабрики позволяют лучше это организовать.
Но как я писал, все это дело вкуса, это лишь еще одна альтернатива. И поскольку он опциональный, то вы смело можете использовать любой другой DI компонент с PHPixie фреймворком.
На самом деле все это дело вкуса, так как самое важное это насколько вам нравится работа с контйнером. Я думаю phpixie di достаточно отличается своим интерфейсом от других чтобы не быть велосипедом, а вот какой интерфейс работы нравится больше уже решать вам.
как я писал в самом начале статьи, совсем не люблю конфигурацию зависимостей в конфиг файлах, а настройка его через PHP более громоздка, e.g.:
> Поясните, что вы конкретно имеете ввиду, используя устоявшуюся терминологию.
Настраивать PHPixie DI можно только изнутри самого класса во время создания екземпляра через protected методы. То нельзя просто так взять и добавить новое значение где-то потом в рантайме, как с Pimple:
> Это ухудшает взаимодействие и опускает DI до уровня Service Locator или синглтонофасадов Laravel.
Как я уже писал вначале статьи, я считаю что контейнеры сильно проигрывают стандартным классам фабрик, и этот компонент написан на случай «если кому-то очень хочется контейнер». Если разработчик сам вправе решать использовать контейнер или нет, он также должен иметь право использовать синглофасады если захочет. Конечно же никто не мешает просто их не использовать если не хочется.
Я не спорю конечно что компонент симфони в совсем другой лиге. PHPixie DI больше создает конкуренцию легковесным контейнерам типа Пимпл и Аура
Если сдается примитивным, пишите которые фичи вам надо, может и появляться =)
2. Я всегда сначала пишу статью на хабр, смотрю фидбек, перевожу на англ и тогда уже ставлю в доку. Так что статья это бета тест доков ))
3. Спасибо, на самом деле у меня PHPStorm, но вот как раз эту либу писал в Атоме
и все =)
На твиттере от меня никто не отписался, никто не зашел в чат и не сказал «все, завтра переписываю», даже звездочек на гитхабе на 2 больше стало. То есть, единственные кто бушует то те кто и так его не использовал ))) Это типа как феминистки против игр выступают, которые они бы и так не купили )))
С типом конечно история жесть, но напомню еще раз что я первый в треде FIG спалил что это не чисто.
Если бы это все был я, то уж так бы не палился: нагенерить звезд на гитхабе и потом самому же твитнуть об этом как то не слишком умно
Ооо нет, только давайте здесь не начинать )))
Если интересно, заходите к нам в чат, я там скоро буду: https://gitter.im/PHPixie/Hotline