Меню
Что нового?

php_templates в виде класса

  • Автор темы Автор темы rudik
  • Дата начала Дата начала
ONK:
Про скорость я понял. Но согласись, что на таких извращенных данных, на какие натравливается tmpl_set, другие движки подобного же класса просто загнутся (образно)... Посмотри test2.php. Вообще все эти тесты, кроме test0.php, который переделан из test.php, выдернуты из исходников php_templates и немного переписаны.

Winnie Pooh:
Я не настаиваю :) Надеюсь что скорость увеличить удастся...

По тому же адресу лежит новая версия. Это Final Candidat, т.к. проходятся все тесты, как su1d-а, так и Тони...

ЗЫ. Пофиксить ничего, о чем тут обсуждали, не успел... будет, видимо, в следующей версии...

ЗЫЫ. Достали пытаться скачать profTemplate.zip. Для таких продублировал...
 
2all:
Кто нибудь пробовал заменитель в "боевой" ситуации? Тесты-то он проходить может, но на реальных задачах спотыкаться...

[Лирика]
Мдя, со скоростью труба... убирание всех маленьких функций в скорости ни черта не дала... Пришел к выводу, что внутренние данные храняться неправильно :( Та структура какая есть сейчас - самая интуитивная. Но выливается в массивы неограниченной размерности и в цикличность всей структуры.
Есть идея структуры с ограничением в максимум 4-мерным массивом и без цикличности... Буду пробовать реализовать ее...
Еще, блин, это экстеншен, позволяет иметь в шаблоне контексты и теги с одинаковыми наименованиями, но в разных контекстах. Те же tplTemplatez и PEAR::IT(X) не позволяют иметь контексты (блоки) с одинаковыми названиями, про теги не уверен, но похоже, что тоже...
[/Лиририка]
 
У php_templates 1.7 крайне неудачная реализация интерфейса инициализирования блоков, данных, вобщем всего.
Именно из-за этого он всего на 20 - 25% быстрее моего простенького обработчика шаблонов, написанного на ПХП. Лично я думаю что твоя реализация совсем не плохая, просто сделать _значительно_ быстрее с таким интерфейсом просто невозможно.

Жду 1.8 с объектным интерфейсом...
 
Кстати твой клас очень хорошо экономит память... Не зря ты ссылки везде использовал.
При генерировании 1000 блоков твой класс раздувал Апач всего на 2мб, а экстеншен на 10 -15. Так что способ хранения данных у тебя правильный.
 
При генерировании 1000 блоков твой класс раздувал Апач всего на 2мб, а экстеншен на 10 -15
Нажмите для раскрытия...
Мдя, а скорость при этом? Сдается мне, что не сильно... Тут в общем, либо скорость большая и памяти кушаем много, либо скорость маленькая и памяти кушаем мало...
Так что способ хранения данных у тебя правильный
Нажмите для раскрытия...
Для заменителя может и правильный, но мне-же самому нужен движок, где скорость уже критична... По большому счету данные представлялись в виде дерева, на подобии того, как это делает dom. В общем все-рвно буду пробовать изменить сруктуру данных :) Не отговоришь :) Там предполагается вообще отсутствие ссылок :) Если руки дойдут до C (уже года 2 не программировал на нем ничего), то напишу экстеншн :)
 
Да, ONK, ты все время говоришь про "свой простенький обработчик шаблонов". А посмотреть на него можно? Или он закрытый?
 
Мдя, а скорость при этом? Сдается мне, что не сильно... Тут в общем, либо скорость большая и памяти кушаем много, либо скорость маленькая и памяти кушаем мало...
Нажмите для раскрытия...
Нет, это никак не связано.
(если интересна скорость то 47милисекунд против > 6секунд не пользу твоего класса -(... )

Не отговоришь Там предполагается вообще отсутствие ссылок
Нажмите для раскрытия...
Отговорю, -), если хочеш сделать что-то быстрое даже не думай заимствовать интерфейс из php_templates 1.7, это не эффективно.

Если руки дойдут до C (уже года 2 не программировал на нем ничего), то напишу экстеншн.
Нажмите для раскрытия...
Если 1.8 затянется ещё месяца на 4 - 6, я наверное найду свободное время и и замусь оформлением своего обработчика в виде экстеншена.... В пинципе я копался в исходниках, объекты в ПХП создаются и хранятся почти также как массивы, даже примерчик присмотрел на будущее. Кстати рекомендую, есть в ПХП предопределённый класс Directory, у него даже три метода есть,,, надо будет изучить его исходники (когда будет время)...

Исходники своего обработчика дать немогу, (не имею права), но он тебе особенно интересен не будет, он оптимизирован под высокую скорость и не обладает большой гибкостью, хотя свою задачу решает успешно.
 
Отговорю, -), если хочеш сделать что-то быстрое даже не думай заимствовать интерфейс из php_templates 1.7, это не эффективно
Нажмите для раскрытия...
Интерфейс это функции для работы с шаблоном? Если да, то как тогда? - по мне это самый интуитивный вариант... Все, что выдел в других классах (IT и tplTemplatez) не блещет своей интуитивностью... Или ты имел ввиду функции по сравнению с методами объекта?

PHP, расслабляет... ведь написал года два назад на С парсилку логов сквида с апачем... а сейчас даже не помню, чего с чем там едят :)
 
ONK:
Сказал, "А", говори и "Б" :) Как там насчет эффективного и интуитивного интерфейса?
 
Эффективный интерфейс это один объект у которого есть куча методов, а не функции принимающие в качестве аргумента специальные объекты...
Возьми к примеру PEAR IT, очень неплохая штука...
 
ONK:
Из твоих слов следует, что если запустить тот же тест (test1) но переписанный под использование класса (в основе, то лежит класс), то он отработает намного быстрее?.. Не верится как-то... Я конечно попробую, но уже завтра...
 
Нет, простое переписывание существенно не поможет, да оно того и не стоит, написал рабочий заменитель и хорошо.

Отдельный обработчик шаблонов писать не имеет смысла, их много и на любой вкус, нужны навороты возьми SMARTY...
 
.
Отдельный обработчик шаблонов писать не имеет смысла, их много и на любой вкус, нужны навороты возьми SMARTY...
Нажмите для раскрытия...
Обработчик уже, собственно, написан. Вот 3 причины, почему писалось своё:
1) Smarty очень сложный (не для меня, а для клиента) да и громоздкий - мне он чем-то напоминает забивание гвоздя микроскопом...
2) У всех виденных мною обработчиков шаблонов (tplTemplatez, PEAR::IT(X), какие-то ещё - названий уже не помню) срывает крышу от конструкций вида (синтаксис php_templates):
<tmpl:block>
<tmpl:block>
</tmpl:block>
</tmpl:block>
т.е. от вложений блоков с одинаковым именем один в один.
3) Аналогично (2) и с передачей параметров в скрипт (например, количество записей для отображения на странице)

На вопрос: "А нифига такое?" - уже есть ответ: "Доцент (читай заказчик :)) тупой. Чем в меньшем количестве файлов ему нужно (да и необходимо) что-либо править и чем меньше имен (контекстов) запоминать, тем лучше..."
У меня заказчики какие-то "тупые" пошли: "нужно то-то и то-то и чтобы работало сразу или с минимальными правками в минимальном кол-ве файлов"...

Я идею изменения структуры данных оставил на потом -заказчик проявил активность :). Использую, что написал...
 
Profic

Вот такое вылезает на каждый
тег - сам шаблон показывается - но не парсится

Warning: [profTemplate/1.0RC1 line:461] Undefined tag/context "./menu_id" in lib\profTemplate-prefork.class.php on line 268
 
admin
новая версия лежит по старому адресу

PS. Там есть одна беда, я нечаянно убил поддержку Дримваверских шаблонов :(

PPS. Еще одно: в коде в данный момент времени имеется 2 реализации кода, старая и новая вичищать буду попозжее
 
все равно не работает, на каждый тег выдается:

Warning: [profTemplate/1.2.0-RC1] Undefined tag/context "/relatedlinks/headerlink/LINK" in /www/hosts/blus/includes/profTemplate-new-data-struct.class.php on line 400

этим классом кто-нибудь занимается, пользуется?
 
Спроси у Profic ...
Имхо что он написал не очень производительное..
 
Если кого-то вдруг заинтересует.. Есть еще один "php_templates в виде класса", несколько похожий на творение Profiс/su1d'а, только с серьезно расширенной функциональностью, ну и скорость неплохая судя по тестам.

Было заюзано знакомыми и потестено в боевых условиях... Потом у меня появилось большое количество работы и я отказался от поддержки.

Если кого-то интересует - отдам в хорошие руки
http://algolist.manual.ru/madtemplate/
 
Sizz
раскомментируй строку 401 (там где идет print_r) и погляди, что не так. Если не поймешь сам - то кидай вывод сюда)

А насчет новой версии: есть идеи, но реализовано все будет на php5. И то если будет. Я сам возможно пересяду на Smarty :)

-~{}~ 30.06.04 14:05:

algo
у тебя в шаблонизаторе, насколько я понял основная проблема "несколько похожий". У моего же имется нативный интерфейс вместо php_templates.
 
algo
у тебя в шаблонизаторе, насколько я понял основная проблема "несколько похожий". У моего же имется нативный интерфейс вместо php_templates.
Нажмите для раскрытия...
- Итак, Вас по-прежнему мучают эротичесике сновидения ?
- Хм, доктор, ну почему же мучают..
 
Войдите или зарегистрируйтесь для ответа.
Сверху