-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Шаблонный движок
- Автор темы makvik
- Дата начала
Alexandre
PHPПенсионер
это зависит от реализации libxslt
для распараллеливания необходимы специальные команды для процессора. т.е. мы можем параллельно выполнять только потоки и процессы ( процесс является главным потоком ). Если алгоритм реализации libxslt допускает разбиение вычисления на потоки, то тогда это возможно. мне кажется - нет.
-1, недостаток: скорость.
+1 если заранее известно, что кол-во данных для преобразования небольшое (не более 100 узлов), необходимо иметь несколько видов сайтов: HTML, WAP, PDA etc...
а так, я за шаблонизацию native-PHP (солидарен с Фaнатом),
пример использования здесь
в крайнем случае за смарти... хороший и довольно простой шаблонный движок VLib...
для высоконагруженных проектов рекомендую blitz или ctpp.
вообще - не все ли равно, какой шаблонизатор использовать??
можно использовать любой, главное, чтоб по нему была толковая документация.
dark-demon
d(^-^)b
сомневаюсь.. реализация xslt на яваскрипте занимает 100кб кода, на пхп будет раза в два больше.
korchasa
LIMB infected
Я имел ввиду какое-то внешнее по отношению к выполняемому скрипту решение - демон, например, который будет строго заниматься компиляцией, ну и каким то своим кешированием, наверное. Наверняка такое уже есть, и надо просто покопать.
Просто на мой взгляд если уж использовать xml/xslt, то ради единения формата данных, и соответственно, независимости от реализации отдельных блоков. Не хватает скорости - переписал на что-то ниже уровнем. Без штук, типа поднятия процесса для exec'а в пыхе, чтобы запустить башевый скрипт.
Хотя с другой стороны (X)HTML тоже какой-никакой стандарт, и ту же самую независимость можно через nginx+ssi получить. Ну разумеется там, где блоки не связанны общими данными.
А касаемо темы - мои сегодняшние бенчи показали, что сложная страница на {{MACRO}} без компиляции, кеширования опкода и тюнинга, отдается на рабочей машине за 5 сотых, что вполне устраивает, т.к. одно кеширование, чем-нибудь типа APC должно дать прирост на пару порядков.
CatManZero
Новичок
Куда уж php тягаться с libxslt, написанном на С.
Но всё-таки... Неужели xml/xslt на столько сложные по сравнению с php, что столько времени уходит на разбор и интерпретацию
dark-demon
d(^-^)b
> А при чём здесь реализация на яваскрипте?
при том, что это будет неповоротливый монстр.
> Кстати я когда то делал XSLT процессор, ещё на PHP4, заняло всего 40 кб...
ты реализовал все функции xpath и элементы xslt?
кстати, я тут поэкспериментировал...
прежде всего я вынес формирование массива данных за пределы цикла. далее я переписал рекурсивное формирование хмл-я на итеративное, и, наконец, я создал сотню одинаковых пхп-темплейтов дабы нивелировать влияние байт-код кэша на результаты.
итого:
пхп-темплейты - 37мс
сериализация в хмл - 40мс
при этом по прежнему использовались ультра-простые темплейты. на темплейтах приближенных к реальным пхп должен солидно тормознуть в то время как сериализация в хмл зависит только от объёма входных данных.
при том, что это будет неповоротливый монстр.
> Кстати я когда то делал XSLT процессор, ещё на PHP4, заняло всего 40 кб...
ты реализовал все функции xpath и элементы xslt?
кстати, я тут поэкспериментировал...
прежде всего я вынес формирование массива данных за пределы цикла. далее я переписал рекурсивное формирование хмл-я на итеративное, и, наконец, я создал сотню одинаковых пхп-темплейтов дабы нивелировать влияние байт-код кэша на результаты.
итого:
пхп-темплейты - 37мс
сериализация в хмл - 40мс
при этом по прежнему использовались ультра-простые темплейты. на темплейтах приближенных к реальным пхп должен солидно тормознуть в то время как сериализация в хмл зависит только от объёма входных данных.
CatManZero
Новичок
Полностью согласен. Потому и выбрал для следующего проекта {{MACRO}}. Сайт, обещают, будет достаточно посещаемым. Причем работать будет не в самых идеальных условиях. Не хотелось бы, чтоб xslt стал главным тормозом. Тем более, что он (xslt) является PushView-шаблонизатором, и требует дополнительной подготовки данных перед трансформацией. Это естественно приводит к дополнительным расходам ресурсов.
atv
Новичок
Я точно не знаю, но помоему там шаблоны не компилируются, а преобразование производиться непосредственно с DOM деревом. К тому же, там каждый раз происходит парсинг шаблона в DOM дерево.
ты, скорее всего, не до конца понимаешь идею компиляции, а уже делаешь такие выводы, ладно, не парся.
XSLT элементы где-то 80%, XPath - практически всё.
-~{}~ 14.01.08 21:59:
Что ты имеешь ввиду? Если данные понадобятся, то неважно когда они будут подготовлены, перед трансформацией, или во время...
Кстати, именно PushView-шаблонизатор является идеологически правильным шаблонизатором. В момент, когда пошло отображение, все вычисления должны быть уже закончены, и шаблонизатору должны быть переданы уже подготовленные данные. А шаблонизаторы, которые дёргают PHP код, вносят, только, дополнительные зависимости между слоями приложения.
dark-demon
d(^-^)b
> Тем более, что он (xslt) является PushView-шаблонизатором, и требует дополнительной подготовки данных перед трансформацией.
и это есть труъ! шаблон - это не вью. вью - это не только шаблон.
и это есть труъ! шаблон - это не вью. вью - это не только шаблон.
CatManZero
Новичок
Сорри. Я немножко запутался в терминологии
В общем это касается реализации конкретного View на базе XSLT:
В случае с xslt я просто вынужден буду сделать копию данных, полученных из БД, ещё раз в виде DOM. Вот вам и расход ресурсов: времени и памяти.
В шаблонизаторах на базе php можно напрямую или косвенно (через врапперы, декораторы и т.п.) работать с dataset.
dark-demon
ссылку посмотрел, действительно работает. правда смущает, что там шаблон крайне простой. наверняка если захотеть что-то посложнее, вылезут всякие приколы, ага?
>шаблон - это не вью. вью - это не только шаблон
а вот это высечь в золоте.
почему-то мало кто это понимает. кроме xslt-шников, которые почему-то ничего больше не признают. как страшно жить
ссылку посмотрел, действительно работает. правда смущает, что там шаблон крайне простой. наверняка если захотеть что-то посложнее, вылезут всякие приколы, ага?
>шаблон - это не вью. вью - это не только шаблон
а вот это высечь в золоте.
почему-то мало кто это понимает. кроме xslt-шников, которые почему-то ничего больше не признают. как страшно жить
dark-demon
d(^-^)b
ну, кроме косяков в опере ничего там особенного не вылезает 
dark-demon
d(^-^)b
я ж не предлагаю совсем отказываться от поддержки оперы
самый серьёзный баг - неработающие формы - решается одним из следующих способов:
1. для оперы делаем трансформацию на сервере как минимум для страниц, содержащих формы.
2. указываем method="xml", но тем самым переводим ие в режим даунизма
3. используем хак с двойным указанием метода - решает проблему даунизма ие, но не работает в третьей лисице.
4. динамически меняем метод в зависимости от браузера
5. сабмитим формы с помощью ajax.
самый серьёзный баг - неработающие формы - решается одним из следующих способов:
1. для оперы делаем трансформацию на сервере как минимум для страниц, содержащих формы.
2. указываем method="xml", но тем самым переводим ие в режим даунизма
3. используем хак с двойным указанием метода - решает проблему даунизма ие, но не работает в третьей лисице.
4. динамически меняем метод в зависимости от браузера
5. сабмитим формы с помощью ajax.
dark-demon
d(^-^)b
именно _поддерживать_ xslt проще. при условии, что никто не налепит туда шаблонов в стиле пхп - тогда ясен пень - хрен редьки не слаще