Не могли бы Вы подробней рассказать, в чём смысл данного подхода к рендерингу? Я видимо сильно отстал от жизни, но неужели фрёймворк предполагает полностью перенести рендеринг на плечи браузера, тем самым сделав сайт вообще никаким при неработающем javascript'e?
PS: Это желание понять в чём идея, а не похоливарить.
зачем нужно 10 различных синтаксисов вставки значения в строку? о_0
как он воспримет ситуацию, когда внутри name у меня будут кавычки, угловые скобки да амперсанды? и наоборот, можно ли вставить сырой хтмл вместо плейсхолдера?
>зачем нужно 10 различных синтаксисов
Завет председателя МАО: «Пусть расцветает 100 цветов, соревнуется 1000 школ». Вечный холивар PHP-программистов какой темплейтор лучше должен плавно переползти в JS.
Но мы то знаем, какой темплейтор для xHTML единственно верный :)
Может расскажете, в двух словах, как работает пример?
Как PURE узнает, что заменять нужно class=«context», как он узнает какой имеено из двух нужно заменять, как узнает, какая иерархия должна быть у размноженных элементов. Не очень то улыбается использовать фреймворк, который работает на здравом смысле вместо четкого алгоритма :)
Собственноя я тоже ничего не понял.
Сначала мне нужно в РНР данные собрать потом их передать в JS а потом уже при помощи JS отрисовать эти данные?
Как по мне это много мороки, и она абсолютно не оправдана.
во-первых, как я понимаю, Вам не придется запариваться с шаблонами в PHP. Вы просто передаете набор данных JS-шаблонизатору.
во-вторых, с этим шаблонизатором возможна перерисовка интерфейса вообще без участия сервера. один раз получаем набор данных и дальше оперируем ими на клиенте как хотим.
на мой взгляд, очень интересный подход. в сложных интерфейсах может быть вполне оправдан.
да согласен на все 100% рендерить данные должен клиент а не сервер и вся логика их рендеринга должна быть у клиента это во первых разгружает сервер во вторых дает клиенту возможность самому отрендериить как он хочет но это на уровне идеи сама идея мне нравится реализацич на ЖС? нууу крепко подумать стоит прежде чем делать это
Я тоже ни во что не въехал, но у меня есть предположение:
Есть к примеру стандартное диалоговое окно, которое встречается на сайте много раз. У него есть загаловок, текст и кнопки. Само окно где-то невидимое хранится в ДОМе. А для вставки в него нужных кнопок, загаловка и текста при вызове и может применяться шаблонизатор. Как-то так.
Скорее всего (как и писали выше) это для веб-приложений с активным использованием AJAXа (такого, где от сервера к клиенту идут XML или JSON данные, а не готовые HTML блоки). HTML из данных и шаблона генерируется уже на клиенте… Чисто Client-Side MVC.
Мы для этих целей пользуемся Javascript MVC, которую тут на Хабре уже вроде описывали.
конкретно эта реализация шаблонизатора не нравится.
заменить содержимое пары тегов на значения из массива с помощью того же жКвери итак в две строчки можно. а вот чтобы более-менее сложный контент сорфмировать, надо будет захламить всё классами специальной нотации (unobstructive говорите?) и понаписывать своих функций-директив.
но сделать что-то качественное и чтобы не тормозило конечно непросто в этом направлении. да и вопрос нужно ли
То есть без яваскрипта ничего работать не будет. И с какой скоростью обработается допустим 500-Кб страница, тоже неизвестно? Закапывайте, нафиг это нужно.
Вот простой пример что пришел в голову:
Анкета участников и кнопки «вперед», «назад», жмем вперед, аяксом получаем только поля и вгоняем в шаблонизатор… трафика меньше… работы по обновлению анкеты еще меньше
Чистый шаблонизатор — PURE