Ну… Можно xslt, можно шаблонизировать на сервере или клиенте ведь. Однако php — по своей задумке и есть шаблонизатор, так что его появление около html тегов понятно и объяснимо.
Данные о товарах (цены, категории, названия, описания) очень удобно держать в регулярно перегенерируемых json-файлах и отдавать из nginx'ом как статику.
Поясните, пожалуйста, в каком случае? Когда у нас одностраничное приложение на js, которое им же шаблонизируется, визуализируется?
Я просто работал с магазинами и слабо представляю зачем мне js с данными на тридцать тысяч товарных предложений. Хотя там и сложный расчет скидок и карты и складов много, etc в общем.
иногда бывает лучшим решением подключить PHP и сгенерировать содержимое JS-файла «на лету» (например, получить актуальные цены на продукты из БД и передать их JavaScript-программе для валидации формы заказа)
Курсивом выделено некорректное 'если'. В этом случае нам нет никакой необходимости включать php код в js. Это не пример лучших практик, скорее наоборот.
Вашу задачу можно сформулировать так:
как включить обработку php-кода в формате, отличном от .php
Понимаете какая детская задача?
И эти утверждения будут верными, пока вы не приведете живого примера, когда это и правда полезно и несет какую-то выгоду.
Она жалуется, что ее не благодарят? Мне одному кажется, что это клиника какая-то? Вдумайтесь только.
Черт, реально быть уверенным что человек обязан тебя поблагодарить это нечто.
ИМХО codestyle тут решит. Согласитесь, же, что если в корпоративном стиле для классов у нас '_', все слова в переменных разделяются восьмеркой, а функции начинаются с заглавной буквы — все вроде бы нормально :D
Но это уже наболевшее, спасибо за ответ, просмотрел, что у автора классы так называются.
Кто бы спорил, что один нормальный JOIN по индексам будет медленнее 560*[необходимое количество отношений] запросов. Для трех отношений(пост->(комменты, пользователь, рейтинг)) получается больше полутора тысяч запросов :D Не думаю что кто-то додумается до такого на production.
Я это к тому, что может и была проблема, но в последних версиях AR Yii вполне себе здорово вправляется с большими выборками. Если профайлер покажет проблему — да, стоит использовать DAO. Но предварительная оптимизация зло.
Очень интересно. Я только сейчас нашел, где мне реально могут понадобится большое количество AR моделей.
Yii: trunk
Количество моделей: 560
Столбцов: 12 (text, varchar, int, enum, timestamp)
Память: 5,450Кб
Я вывел интересующую меня информацию по 560 моделям, естественно без использования отношений. Никакого кеширования, сервер локальный не настроен совсем.
Так что если оставить за бортом рациональность подобного подхода(у меня например эта страница полностью кешируется — мне один раз памяти не жалко чтобы сохранить единообразие) — не так уж оно и течен.
Я именно поэтому и добавил — 'Хотя это и не совсем то.'
Однако вы не ответили на вопрос. О какой ситуации вы говорите, когда AR с массивом моделей не подходит? И на каком количестве записей будет ощутима потеря производительности?
// не подходит для больших выборок
Вы про накладные расходы при создании обьектов? Если это правда будет проблемой есть DAO, который не менее удобен. Хотя это и не совсем то.
В таком случае возможно это и служило какой-то цели и сэкономило время/деньги.
Но честное слово, лучше бы вы написали статью о борьбе с кучей лапши, доставшейся вам, чем о том, как .js заставить понимать вставки php кода.
Ну… Можно xslt, можно шаблонизировать на сервере или клиенте ведь. Однако php — по своей задумке и есть шаблонизатор, так что его появление около html тегов понятно и объяснимо.
Это критически важно для принятия решения — 'вот, блин фигню сморозил' или 'вот это у него задачи, что он так хитро вывернулся'.
Поясните, пожалуйста, в каком случае? Когда у нас одностраничное приложение на js, которое им же шаблонизируется, визуализируется?
Я просто работал с магазинами и слабо представляю зачем мне js с данными на тридцать тысяч товарных предложений. Хотя там и сложный расчет скидок и карты и складов много, etc в общем.
startof nudnik_mode
rPman, только лучше что-то вроде
А то вдруг придется резко расширить функционал под быстро меняющиеся требования :)
endof nudnik_mode
Курсивом выделено некорректное 'если'. В этом случае нам нет никакой необходимости включать php код в js. Это не пример лучших практик, скорее наоборот.
Вашу задачу можно сформулировать так:
Понимаете какая детская задача?
И эти утверждения будут верными, пока вы не приведете живого примера, когда это и правда полезно и несет какую-то выгоду.
Черт, реально быть уверенным что человек обязан тебя поблагодарить это нечто.
Но это уже наболевшее, спасибо за ответ, просмотрел, что у автора классы так называются.
Почему так неуверенно? json_encode($data) -> получаем нативный массив
Или от такого подхода Yandex станет меньше в названии метода? :)
Я это к тому, что может и была проблема, но в последних версиях AR Yii вполне себе здорово вправляется с большими выборками. Если профайлер покажет проблему — да, стоит использовать DAO. Но предварительная оптимизация зло.
Yii: trunk
Количество моделей: 560
Столбцов: 12 (text, varchar, int, enum, timestamp)
Память: 5,450Кб
Я вывел интересующую меня информацию по 560 моделям, естественно без использования отношений. Никакого кеширования, сервер локальный не настроен совсем.
Так что если оставить за бортом рациональность подобного подхода(у меня например эта страница полностью кешируется — мне один раз памяти не жалко чтобы сохранить единообразие) — не так уж оно и течен.
Однако вы не ответили на вопрос. О какой ситуации вы говорите, когда AR с массивом моделей не подходит? И на каком количестве записей будет ощутима потеря производительности?
Вы про накладные расходы при создании обьектов? Если это правда будет проблемой есть DAO, который не менее удобен. Хотя это и не совсем то.