поэтому и пишу сюда

Для Mongo - кроме MongoDB есть еще что-то удобное? Почему-то устаревший Mongo - работает куда интереснее

Задача - посчитать количество элементов

Простой Query - возварщает все объекты, а меня сами объекты не интересуют - только количество

Спасибо всем) разобрался. Через Command делается

Не спится?)

Ну (

Не спиться бы

Ну (

А нефиг в три ночи работать)

привет, кто в FF использует Selenium IDE :)

нажимаю на input type submit - и всё, тупик. страница перегрузилась, а дальше действия не делает

clickAndWait

Всем привет, пишу велосипед, нужна критика, здесь можно публиковать ссылки на свои мега-пакеты?

можно, почему нет

https://github.com/php-vivace/di Если кому не лень, посмотрите, хотелось бы услышать есть ли аналоги, замечания по реализации. Это очередной контейнер, но тут пригодились кое-где контейнеры с возможностью расширения. Что бы можно было написать модуль, описать зависимости модуля, а этот модуль уже можно включить в другой модуль, и так далее.

https://github.com/php-vivace/di Если кому не лень, посмотрите, хотелось бы услышать есть ли аналоги, замечания по реализации. Это очередной контейнер, но тут пригодились кое-где контейнеры с возможностью расширения. Что бы можно было написать модуль, описать зависимости модуля, а этот модуль уже можно включить в другой модуль, и так далее.

В чем отличие от php-di?

А этот чем не подошел?

https://symfony.com/doc/current/components/dependency_injection.html

В чем отличие от php-di?

потому что в его реализации нет фатального недостатка*

Ну кроме

В чем отличие от php-di?

Более простая реализация с возможностью расширения контейнеров

Более простая реализация с возможностью расширения контейнеров

Что за возможность расширения контейнеров?

Что за возможность расширения контейнеров?

например, есть модуль, например блог, он может работать как сам по себе так и в контексте другого приложения. Так вот, команда программистов написала контейнер для блога в котором объявили и зарезолвили все зависимости. Другая команда, берет этот модуль блога, и встраивает(наследуют) все его зависимости в свой сайт, заодно резолвя коллизии(например в нашем приложение есть \PDO::class и у блога есть \PDO::class, и для блога надо подсунуть другой коннект)

Вот кусок из примера где происходит встраивание другого контейнера $this->use(new PackageA()) //Disable the cache through the use of "DummyCache" for "vendor\tool\ClassB" ->insteadFor('vendorA\tool\ClassB', \vivace\di\Package::new([ \Psr\Cache\CacheItemPoolInterface::class => 'cache.dummy' ])) ->insteadOf(\Psr\Cache\CacheItemPoolInterface::class, 'cache.redis') ->insteadOf(PDO::class, 'db.second');

Короче наследование для конфигов. Звучит как ад

Так а симфони контейнер не подходит?

Простой Query - возварщает все объекты, а меня сами объекты не интересуют - только количество

возвращало тебе не обьекты, а курсор на котором можно вызвать count метод

возвращало тебе не обьекты, а курсор на котором можно вызвать count метод

count (...->toArray()) ? он упиарлся в лимит 16мб cap и отваливался

Метод

->count ()

у cursor разве есть метод count?

http://php.net/manual/ru/class.mongodb-driver-cursor.php

Ой, хз)

Ну я тоже предполагал что там есть этот метод :) но его нет... в Общем через Command все красиво и быстро решилось

а да, забыл что на новом драйвере нет

https://docs.mongodb.com/php-library/master/reference/method/MongoDBCollection-count/

тогда вот

Ага, его реализовал как раз. Спасибо

Короче наследование для конфигов. Звучит как ад

Ну почему же? Как резолвить зависимости для сторонних модулей(в которых более 10 классов)? лучше это делать в index.php ? Тут основная цель это переносимый контейнер, у тебя есть набор из 20 классов, все это для работы твоего модуля, что бы просто запустить твой модуль нужно подключить твой контейнер в котором уже зарезолвины зависимости. С контейнером из симфони я так и не понял как наследовать или встраивать чужой контейнер?

всмысле в контейнер симфони поместить еще один контейнер? Или заменить? Это компонентный фреймворк из него можно выпелить все-что угодно.

всмысле в контейнер симфони поместить еще один контейнер? Или заменить? Это компонентный фреймворк из него можно выпелить все-что угодно.

Ага, именно это, один контейнер, встроить в другой контейнер(чем то схоже с трейтами) и использовать его фабрики + нужен функционал для решения коллизий. Например я встраиваю два контейнера, в которых объявлены \PDO::class или Psr\LoggerInterface и мне надо что бы внутри одногоо контейнера логи писались в файл, а в другом логи уходили на другой сервис

Это же можно сделать средствами ООП и двух объектов

зачем два контейнера?

зачем два контейнера?

Конечно это можно просто наследовать и ручками инъектить зависимости. Цель всех этих контейнеров, как мне кажется, это сократить кол-во рутины, за счет того что обычно в стороннем модуле тебе надо поменять пару зависимых компонентов, а все остальные решения зависимостей оставить так, как это было заложено разработчиком модуля.

Всмысле инъектить ручками? Есть же конфиг, создаем сервисы, один сохраняет в файл/другой в базу например и все. Используем где хотим.

Контейнер не только для этих целей сделан, которые вы описали

Ага, именно это, один контейнер, встроить в другой контейнер(чем то схоже с трейтами) и использовать его фабрики + нужен функционал для решения коллизий. Например я встраиваю два контейнера, в которых объявлены \PDO::class или Psr\LoggerInterface и мне надо что бы внутри одногоо контейнера логи писались в файл, а в другом логи уходили на другой сервис

Вы мыслите какими-то странными терминами

Контейнер в приложении один

Если их больше, то что-то не так

Конфиг для контейнера и контейнер это разные вещи

Живут отдельно

Наследовать что-то с поведением - неправильно в принципе

Если вам в ваше приложение надо подключить какой-то сторонний модуль, то конфигурируете классы как вам надо либо прямо используете их конфиг

И вуаля

Не надо ничего никуда встраивать

Скоупы вроде ничешная идея, но не уверен, что оно в принципе нужно

Всмысле инъектить ручками? Есть же конфиг, создаем сервисы, один сохраняет в файл/другой в базу например и все. Используем где хотим.

Инъектить ручками имел ввиду new Object(new EmbedObject(), new EmbedObject2(new DeepObject())); У меня подход другой, контейнер создается для каждого модуля(пакета) свой, модуль это самостоятельное приложение не знающее о том что там выше. Вы говорите о разрешение зависимости через конфиг для конкретного класса, но если этот класс зависит от нескольких других, которые в свою очередь зависят от других классов, то придется очень много описывать в конфигах, и мне кажется в конфигах это делать не очень удобно, конфиги больше для хранения переменных окружения, а не для управления хода выполнения программы

Инъектить ручками имел ввиду new Object(new EmbedObject(), new EmbedObject2(new DeepObject())); У меня подход другой, контейнер создается для каждого модуля(пакета) свой, модуль это самостоятельное приложение не знающее о том что там выше. Вы говорите о разрешение зависимости через конфиг для конкретного класса, но если этот класс зависит от нескольких других, которые в свою очередь зависят от других классов, то придется очень много описывать в конфигах, и мне кажется в конфигах это делать не очень удобно, конфиги больше для хранения переменных окружения, а не для управления хода выполнения программы

Хм, а для чего вообще вы используете контейнер?)

Это я к последней фразе про ход выполнения

Хм, а для чего вообще вы используете контейнер?)

Имеете ввиду как я использую контейнеры в работе?

Ну а так, надо описывать только те зависимости, которые сами не создвются

Имеете ввиду как я использую контейнеры в работе?

Скорее зачем вы их используете

Инъектить ручками имел ввиду new Object(new EmbedObject(), new EmbedObject2(new DeepObject())); У меня подход другой, контейнер создается для каждого модуля(пакета) свой, модуль это самостоятельное приложение не знающее о том что там выше. Вы говорите о разрешение зависимости через конфиг для конкретного класса, но если этот класс зависит от нескольких других, которые в свою очередь зависят от других классов, то придется очень много описывать в конфигах, и мне кажется в конфигах это делать не очень удобно, конфиги больше для хранения переменных окружения, а не для управления хода выполнения программы

У php-di конфиг на пхп если что

ERROR: S client not available

У симфони вроде тоже можно, это не скажу точно

у симфони можно как угодно

php, xml, yaml

Скорее зачем вы их используете

обычно я использовал так же один контейнер и получалась длинная партянка с одним контейнером в каком нибудь файле типа services.php. Потом стал разделять на множество контейнеров поменьше, группировал их. так постепенно получился велосипед, а сейчас просто решил оформить и привести к нормальному виду

Зависимость классов от классов, решается с помощью Autowire Обычно нужно описать только конфиги для базы и т.д. Ну и какие-нибудь хитрые зависимости, которых обычно не много

?

Да вы конфиг разделяли

А не контейнер ну

Зависимость классов от классов, решается с помощью Autowire Обычно нужно описать только конфиги для базы и т.д. Ну и какие-нибудь хитрые зависимости, которых обычно не много

Да, именно. Обычно надо указать только реализации интерфейсов

А не контейнер ну

Нет, мы не использовали конфиги для разрешения зависимостей, ручками писали как и что надо создать, вплоть до моделей и классов хелперов

Модели в контейнере? О.О

Да, и не только

Более мелкие классы

даже к контенере были

Нет, мы не использовали конфиги для разрешения зависимостей, ручками писали как и что надо создать, вплоть до моделей и классов хелперов

То что вы конфиг в пхп описываете это дело десятое

Чтото не так с кодом

Ручками писали = конфиг

И все-таки зачем вам контейнер?

Нет, мы не использовали конфиги для разрешения зависимостей, ручками писали как и что надо создать, вплоть до моделей и классов хелперов

И вот autowire как выше подсказывают

Ручками писали = конфиг

Нет, писали так $container->define(app\model\User\About::class, [app\helper\User\Factory::class, 'newAbout']);

Ну вот и конфиг

Или вы в рантайме подменяли на ходу еще что-то?)

И вот autowire как выше подсказывают

Ну я же добавил то же контейнер который умеет Autowire(), в README.md внизу там есть)

Или вы в рантайме подменяли на ходу еще что-то?)

Нее, только в одном месте, я под конфигами имею ввиду yaml,ini,json

Уже хорошо)

Так зачем вам контейнер?

Ой ё

В user pdo инъектит контейнер

Так зачем вам контейнер?

Для решения всех зависимостей, что бы все было централизовано и не случалось такого, что понадобился новый объект и приходится его прокидывать с самых верхов)

В user pdo инъектит контейнер

Ну да, для примера написал, а что в этом плохого?