AM
Но autoload map генерится.
Size: a a a
2021 April 07
AB
ну как бы что так что так, мусорные не используемые классы на перформанс повлияют
DS
Понятно, что генерится, но на скорость это не влияет, поскольку ищет по ключам.
DS
Вот и я об этом говорю
AM
@nex_otaku а можешь показать из этого проекта phpunit.xml?
AB
И тут вспомнитается: https://www.npopov.com/2011/12/28/Supercolliding-a-PHP-array
AB
неприменимо конечно
AB
issue в app, где она не очень применима
NO
Только там и есть код реальный чтобы можно было обсуждать ) Так что не согласен с тобой
DS
Какой реальный код? Там нет модулей. Модуль есть в yii-demo, это Blog
NO
Я имел в виду демо ) Если запостил в апп значит по ошибке, перенесу в демо )
NO
Собирался в демо постить
NO
AB
Еще минус, если работаете с верстальщиками, то они вряд ли спасибо скажут, если им придется в src лезть
AB
Куда переносить, к примеру, https://github.com/yiisoft/yii-demo/blob/master/src/Controller/SiteController.php - на отдельный модуль не тянет. Директория Controller на верхнем уровне и внутри модулей?
ПА
а как насчет если юзается AR, и в каждом нужна модель пользака? В каждом хранить?
NO
Не могу за отсутствием оного ) Те файлы что были я показал, "phpunit.xml" в проекте нет.
NO
Очень хороший вопрос, прямо классика, но он относится не к моему предложению "вынести вьюхи и тесты в папку модуля" а к разделению на модули в принципе.
Ответ на этот вопрос давали много раз и нужно писать много текста чтобы полностью объяснить, но если в кратко и в двух словах, то:
1. Да, в тех модулях что используют юзера, везде нужна будет модель юзера, в каждом модуле будет класс юзера. Только так можно обеспечить независимость модуля.
2. В хорошо структурированном приложении модули отделены не только по коду, но и по данным. Это означает, что у каждого модуля работающего с пользователями, если ему требуется хоть что-то кроме ID, будет своя табличка для пользователей с нужными только этому модулю полями, и управление этой табличкой лежит в ответственности этого модуля.
Ответ на этот вопрос давали много раз и нужно писать много текста чтобы полностью объяснить, но если в кратко и в двух словах, то:
1. Да, в тех модулях что используют юзера, везде нужна будет модель юзера, в каждом модуле будет класс юзера. Только так можно обеспечить независимость модуля.
2. В хорошо структурированном приложении модули отделены не только по коду, но и по данным. Это означает, что у каждого модуля работающего с пользователями, если ему требуется хоть что-то кроме ID, будет своя табличка для пользователей с нужными только этому модулю полями, и управление этой табличкой лежит в ответственности этого модуля.
ПА
второй пункт конечно для меня открытие , про несколько таблиц пользователя.
В остальном я так и думал
В остальном я так и думал
NO
Назвали плохо, вот и "не тянет" )
"Site" это отвратительное название, так как абстрактно и ничего не проясняет.
Назови "Home" и сразу появится смысл.
"Site" это отвратительное название, так как абстрактно и ничего не проясняет.
Назови "Home" и сразу появится смысл.