Влад Волынец: Шаблон подразумевает под собой логику. Верстальщику надо будет знать, какие объекты передаеются в шаблон, какие у нах есть поля и методы. Плюс в Yii вьюхи (они же шаблоны) не лежат в webroot, а раскиданы по внутреним директориям: у каждого контроллера/виджета своя вьюха. Если вы хотите, ограничить верстальщика только директориями с шаблоном, то вам придется изгаляться чтобы это сделать.
Проще программиста заставить это делать. У нас тоже есть отдельный верстальщик, фронтенд и бэкенд разработчики. ФРонтенд разработчик пишет код и складывает его в assets директорию (или вообще отдельно, если это sibglepage приложение). Его можно ограничить. А верстальщик просто делает html файлы и стили к ним с рыбными данными. Отдает нам на бэкенд и мы его уже на куски режем, разносим по вьюхам и добавляем логику.
Учитывайте что логика отображения, которая есть во вьюхе, может быть сложнее чем обычные циклы. Например вы показываете список постов и автору надо показать кнопочку редактирования. Вы можете передать в шаблон id текущего пользователя и сравнить его с id автора. Но по уму это делается в отдельном методе, чтобы скрыть реализацию проверки. А есть составные сложные условия.
Мы на своем опыте убедились, что допускать верстальщика до хоть какой-нибудь логики себе дороже.
Alexander Litvinenko: Зачем каждый раз при выводе обрабатывать текст, если можно сделать это один раз при вводе? Если вы предполагаете, что в будущем может, например, измениться список допустимых тегов, то можно держать еще и оригнальный текст.
Но ваш подход тоже работает, если кешаровать результат обработки теста. Но, опять таки, делать это надо в модели (в том же геттере).
Влад Волынец: Мне кажется это смутное преимущество. Как замечали выше, шаблонами чеще пользуется не верстальщик, а программист. А у него и так полный доступ к коду. Мне кажется бузсмысленно ограничивать его в этом.
Влад Волынец: Не совсем понял о чем вы, не могли бы поянить подробней. Если вы о возможности вывода только некоторых html тегов, то, как я уже писал выше, я считаю, что это надо обрабатывать при внесении в бд. Там обрезаем или экранируем лишнее, а выводим как обычный текст.
Антон Натаров: Частичное применение шаблонов тоже есть, наследование тоже можно сделать. Единственный плюс шаблонизаторов - автоматическое экранирование текста. Но во-первых это надо в небольшом количестве мест (там, где мы выводим данные введенные пользователем). Во-вторых экранировать лучше при внесении и в бд держать уже нормальный текст.
Спасибо з подробный ответ. Так и сделаю. Только серверне ядро через composer не получится сделать. Приложение подобно wordpress устанавливается и работает. Разработчик может переопределять контроллеры и модели через IoC контейнеры, но основная логика неизменна. А вот дополнительные модули, да, будут через composer ставится. Еще раз спасибо.
littleguga: Стайлгайды в подавляющем большинстве случаев определяются не языком, а фреймворком/библиотекой на которых вы пишите. Есть, конечно, самые распространенные соглашения об именовании в язке, но обычно соглашения, принятые в экосистеме вашей основы, либо совпадают либо имеют приоритет.
Вы бы хоть указали, о каком языке/фреймворке идет речь. Если говорить о компилируемых эссет файлах, то директория должна (но не обязана) называться соответсвенно assets, а внутри биться по версиям (хешам). Но если говорить об обычных публичных файлах, то, как я уже сказал, смотрите в своем ферймворке. Чаще всего это public. А там, как вам захочется. Главное: чтобы понятно было.
Для таких задачь надо делать методы массового редактирования, я не выводить огромную таблицу. Сделайте форму, где можно гибко указать параметры фильтрации и новые показатели. Человек зашел, натыкал фильтры, указал, скажем, новую цену и нажал поменять. Все готоро. И не надо будет для каждого товара (пусть и на одной странице) менять.
Okulo: Разубеждать я вас не собираюсь. Но если вам надо решить задачу бизнеса - то сервис однозначно. В разы быстрее и проще. Если же просто поиграться, то почему бы и нет?
Okulo: А вы планируете это руками все делать? Если программно, то изменение списков рассылок - не вопрос. Какая разница, менять его в приложении на телефоне или в другом приложении?
Okulo: А почему вам надо именно через свой телефон? Спецсервисы удобней (есть история, списки рассылок, отложенные рассылки и т.п.) и дешевле при средних больших объемах.
В первую очередь надо узнать, не надает ли вам оператор по жопе за массовую рассылку? Как бы спец. сервисы работают через api и у них, скорее всего, заключены на это договора. Т.е. там массовость изначально подразумевается. А вот как оператор отнесется к большому потоку сообщений с обычного номера?
Max Khartanovych: Мой комментарий может выглядеть резким. Не хотел никого обидеть. Просто на мой взгляд - это экономия на спичках. Детская болезнь молодых разработчиков, которая со временем проходит. Просто спросите себя: "С каким кодом мне было бы удобней и приятней работать?"
Max Khartanovych: Прирост производительности, о котором вы говорите - это экономия на спичках. Нормальное web приложение редко ворочает такими объемами данных. Если у вас действительно столько строк надо - используйте each() вместо all() и держите в памяти только один объект одновременно.
Суть не в автокомплите, а в том, что объект - это не только данные. Это валидация, работа со связями, внутренняя логика объектов. Если у вас при замене объекта на массив ничего не изменится, то стоит задуматься, а нужен ли вам фреймворк вообще?
Мы в своих приложениях обращаемся к полям через геттеры т.к. там часто есть долп логика. В массиве этого не будет.
Ваш единственный аргумент "удобство разработки" с лихвой покрывает все аргументы о приросте скороси и экономии памяти. Тут все просто: экономить время разработчика намного важнее, чем экономить время процессора и память. Потому что оно в разы дороже. С массивами вы запаритесь потом без внятной типизации.
Вместо этого лучше предусмотрите грамотное кеширование, нормальные алгоритмы, возможность горизонтального масштабирования. Я пишу на Yii с самого выхода первой версии. Написал кучу проектов, среди которых есть и сильно нагруженные. И нигде мы не уперлись в производительность AR.
Если же у вас есть необходимость ворочать большие объемы данных на сервере и это нельзя сделать внутри базы, не передавая их в саму программу, то да - массив может помочь. Но это надо делать только в этом месте, где без этого никак. А в остальном коде используйте удобные плющки объектов и не заморачивайтесь.
Помните, что ваше время дороже времени машины. Вы мой совет вспомните, когда вам придется что-то править в большом объеме кода.
Проще программиста заставить это делать. У нас тоже есть отдельный верстальщик, фронтенд и бэкенд разработчики. ФРонтенд разработчик пишет код и складывает его в assets директорию (или вообще отдельно, если это sibglepage приложение). Его можно ограничить. А верстальщик просто делает html файлы и стили к ним с рыбными данными. Отдает нам на бэкенд и мы его уже на куски режем, разносим по вьюхам и добавляем логику.
Учитывайте что логика отображения, которая есть во вьюхе, может быть сложнее чем обычные циклы. Например вы показываете список постов и автору надо показать кнопочку редактирования. Вы можете передать в шаблон id текущего пользователя и сравнить его с id автора. Но по уму это делается в отдельном методе, чтобы скрыть реализацию проверки. А есть составные сложные условия.
Мы на своем опыте убедились, что допускать верстальщика до хоть какой-нибудь логики себе дороже.