В
@samdark, посмотри, пожалуйста, я все верно описал? https://github.com/yiisoft/yii-console/issues/46#issuecomment-668548890
Size: a a a
2020 August 04
NO
Можно рефлексией пройтись)
NO
Будет достаточно быстро.
AM
@samdark, посмотри, пожалуйста, я все верно описал? https://github.com/yiisoft/yii-console/issues/46#issuecomment-668548890
Да.
В
Благодарю
SI
Вопрос в комментариях в скриншоте. Какой в этом смысл, профит? Решение на строках похоже на магию. Может, что не знаю?
AM
массивы потому как хочется мёржить
AM
единственный профит
AM
как ниже тоже можно
Д
@rustamwin я подумал над индексом, вот решения:
Index - это такой же Collector, только захватывающий несколько сфер (реквест, респонс, прочее).
Создаем новый IndexCollector, в котором будет вся логика по сборам, не тянем себе Request/Response Collector'ы
В любой Storage можно будет прокинуть его несколькими путями:
1. Через новый метод addIndexCollector.
Нужно будет сделать отдельный IndexCollectorInterface, чтобы не подсовывали любой другой.
По завершению работы делаем сохранение основной кучи данных, потом кучи из индекса.
2. Через старый метод addCollector.
Нужно будет сделать интерфейс-маркер, в какую "пачку" сохранять данные из коллектора. Будет основной CommonDataBatch (или без него) и IndexDataBatch, с методами getName - название файла/таблицы/документа, где будут храниться данные.
По завершению работы делаем сохранение данных, группируя их по файлам.
Что скажешь?
Мне нравится 2-й вариант.
Index - это такой же Collector, только захватывающий несколько сфер (реквест, респонс, прочее).
Создаем новый IndexCollector, в котором будет вся логика по сборам, не тянем себе Request/Response Collector'ы
В любой Storage можно будет прокинуть его несколькими путями:
1. Через новый метод addIndexCollector.
Нужно будет сделать отдельный IndexCollectorInterface, чтобы не подсовывали любой другой.
По завершению работы делаем сохранение основной кучи данных, потом кучи из индекса.
2. Через старый метод addCollector.
Нужно будет сделать интерфейс-маркер, в какую "пачку" сохранять данные из коллектора. Будет основной CommonDataBatch (или без него) и IndexDataBatch, с методами getName - название файла/таблицы/документа, где будут храниться данные.
По завершению работы делаем сохранение данных, группируя их по файлам.
Что скажешь?
Мне нравится 2-й вариант.
Д
https://github.com/yiisoft/composer-config-plugin/pull/96
тут апдейт для тестов завезли, гляньте кто-нибудь.
@hiqsol @d_naumenko вы тоже.
тут апдейт для тестов завезли, гляньте кто-нибудь.
@hiqsol @d_naumenko вы тоже.
DN
о, как раз смотрел на него
AM
а это норм что они фейлят?
Д
а это норм что они фейлят?
не думаю :)
T
I don't see the advantage of a separate file to composer.json, it is the same but with another file.
AM
TradersVE
I don't see the advantage of a separate file to composer.json, it is the same but with another file.
It is PHP format so possible to write some logic there if needed.
T
It is PHP format so possible to write some logic there if needed.
I think that the logic should be inside the configuration files, not in their declaration.
AM
It depends...
СП
TradersVE
I don't see the advantage of a separate file to composer.json, it is the same but with another file.
It's conveniently, logically and intuitive. composer.json for configuration composer. And separatelly main file for configuration application.
Config of application in composer.json is not obvious and overload composer.json
Config of application in composer.json is not obvious and overload composer.json
Д
а зачем вообще этот advanced шаблон нужен?