Иной — PHPTAL

[crazyprog]

Великолепная вещь!!1 А с ORM как прекрасно будет работать.

[standov]

да, действительно великолепно — использую с Propel

[standov]

у натива есть 2 огромных минуса:
1. сделанный шаблон (я имею в виду с кодом уже) на доработку верстальщику не вернешь
2. В мешанине html и php сложно ориентироваться — нужная «точка» в TAL шаблоне очень легко находится глазами

[standov]

1. отнюдь, просто я например не вмешиваюсь в работу верстальщика — я не шарю так как он во всех премудростях и так-же не хочу что-бы он вмешивался в мою работу — вот тут разделение и рулит
2. да как не смешай, сейчас один из проектов на ZF c нативными шаблонами, когда перехожу на тал в других проектах — отдыхаю душой и телом, попробуйте.

[standov]

XSLT вещь безусловно крайне мощная но очень неповоротливая и достаточно медленная в реализациях

[nayjest]

Т. е. после вставки инструкций phpTal верстка как правило не разлазится (на практике, вы много делали на нем шаблонов)?
Хм, если так, то это конечно же очень хороший аргумент в пользу такого синтаксиса, т. к. чисто визуально лично я нахожу более приятным что-то такое:

<div id="content">

   <h1>%header%</h1>

   <div>
     %content%
   </div>

   <b>Теги.i18n</b>
   %foreach tags as tag:%
     %tag|escape%
     %separator:%, %end%
   %end%
   <br/>

   <b>'Дата публикации'.i18n</b>
   %format(date,'D M Y')%

</div>

Что вы думаете по этому поводу?

[standov]

извините, я не понял ваш пример, какой участок xhtml верстки тут итерируется?
Да, я достаточно много сделал шаблонов на TALе

[kurokikaze]

Интересная штука :)

[resurtm]

Когда смотрел PHPTAL появилось стойкое ощущение упрощённой lightweight версии XSLT. :) А так отличная штука.

[standov]

в общем да, так и есть, даже область видимости переменных распространяется на узел только XSLT работает с XML а TAL c переменными

[aps]

Шаг.1 Нативный php
Шаг.2 Нативный php заменяются на {макросы}
Шаг.3 {макросы} заменяются на XML
…
Когда php-программисты дойдут до логического конца?

[standov]

а какой конец? XML+XSLT дык дошли и прошли, затык в производительности и цене XSLT специалиста

[aps]

>затык в производительности и цене
И то и другое так часто обсуждалось, что как-то даже неинтересно.
Лучше всего здесь habrahabr.ru/blogs/about_cms/22018/ (Дискуссия разработчиков UMI и Bitrix)

>а какой конец? XML+XSLT
Я вас за язык не тянул :)

[standov]

я говорю о своем опыте а в приведенной вами статье человек пишет маркетинговые лозунги не подтверждая фактами.

В общем, если вас устраивает XSLT — замечательно, технология действительно мощная но я для view его применить успешно не смог.

[aps]

Как-то не заметил маркетинговых лозунгов. Да и смысла упираться Котыреву нет. В его UMI кроме XSLT имеет традиционный шаблонизатор.
Вопрос с производительностью — не вопрос при правильной архитектуре проекта.
Вопрос с кадрами — не знаю. Мои наблюдения совпадают с котыревскими. За месяц нормального верстальщика вполне можно обучить работать с XSLT на более-менее приемлемом уровне.

[standov]

мои наблюдения не совпадают, для вещей в которых xslt имеет преимущества (ключи и группировки) вы верстальщика и за 6 месяцев не обучите поскольку это чистой воды программинг — он уволится. а без этого юзать xslt с предварительным преобразованием данных в XML — это как-то не оправдано мне кажется.
Для меня тал это как-раз та золотая середина — почти xslt только без XML преобразования и «лишних» и навороченных штук

[aps]

Может вы и правы. На хабре каждый второй «девелопер» выступает за неподдержку IE6. Таким уродцам за полгода ключи действительно не освоить. Просто мне везло с верстальщиками.

[standov]

угу, меня — программера по сути и, как я считаю, достаточно опытного :) при словах «группировка Мюнча» начинает типать, группировка описание которой в хорошей книге сопровождается словами «вы все равно не поймете, поэтому просто запомните» осваивать верстальщику.

Объем достойной книги по технологии XSLT порядка 800 страниц и все эти 800 засалены поскольку постоянно к ним обращаешься — вот мой опыт общения с XSLT, очень красиво, чертовски мощно но также и тяжело для хорошего понимания.

[aps]

>при словах «группировка Мюнча» начинает типать
А меня всякий раз, когда приходится учить очередной шаблонизатор, который «намного лучше Smarty» :)
Но метод Мюнха я действительно просто вызубрил наизусть. Правда не помню, когда последний раз его использовал.

[standov]

вот я так не могу, если я чего-то не понимаю в том что использую — плохо сплю, я согласен про новый шаблонизатор, я никого не призываю пересаживаться особенно если все устраивает, это скорее для тех кто в поиске либо кто подыскивает технологию для фреймворка, cms как я когда-то.

[aps]

>я никого не призываю пересаживаться
Тут дело не в насильной пересадке, а в том что нет единого стандарта. В каждой команде php-разработчиков свои вкусы, в каждой CMS свой шаблонизатор.
Поэтому и зверею и спасение вижу только в общепринятом стандарте.
Накладные расходы конечно есть. Но при миграции верстальщика (а я >11 лет верстаю) лучше иметь под рукой стандарт.

[standov]

полностью согласен, для меня именно этот шаблонизатор привлекателен еще и тем что это тоже почти стандарт :)
Zope это почти икона (пусть и не очень удачным названием :)) — wiki.zope.org/ZPT/TALSpecification14

[aps]

>именно этот шаблонизатор привлекателен еще и тем что
>еще и тем что это тоже почти стандарт
И приверженцы Smarty такого же мнения, и у любого другого также 1000 аргументов. А стандарт то только один. И только он включен в PHP5+

>Zope это почти икона
Первый раз я сталкнулся (в качестве верстальщика) с XSLT на Java проекте. Основательно выучил на .NET А уж потом на своих собственных PHP-проектах внедрил.
Вряд ли я единственный кому приходится мигрировать из команды в команду. И работать в нескольуих средах параллельно. Как бы хорош не был Tal — это при таком раскладе не выход.
Я начал с того что все идет к логическому концу. Оно к нему и придет.
Бардак в области разработок среди php-программистов рано или поздно закончится. Придут к единому стандарту. Или двум-трем :)

[egorinsk]

Что-то у меня сомнения, что он генерирует хороший php на выходе, тут эти теги в код так просто не преобразуешь. И да, синтаксис адский.

[egorinsk]

Хотя, вещь, надо признать, интересная, а ограничения, типа «все в аттрибутах» добавляют строгости и уменьшают ошибки.

Но ничего такого, что нельзя сделать в других шаблонизаторах, тут нет,

[standov]

ну наследование реализовано далеко не во всех шаблонизаторах, а вообще да, ничего нового но то что нужно делает красиво и непринужденно

[standov]

попробуйте, по другому я ответить не могу

[galk_in]

Меня зацепили Ваши слова, Ваш верстальщик не школьник.
В защиту верстальщиков-школьников.
По моему глубокому убеждению верстку должны делать верстальщики, а программировать программисты. Поэтому вопрос, standov, вы написали это статью как верстальщик или программист??? Вы же сделали не один шаблон, поэтому должны понимать и тех и других.
Я понимаю что Вам нравиться эта технология, но она для тех людей которые и программируют и делают верстку. А это экономически не правильно. Попробую объяснить почему я так считаю.
Точно так же как есть ModelViewController, есть ДизайнВерсткаПрограммирование и именно верстка это наименее оплачиваемая часть. Или Вы хотите, что бы верстальщик получал за час своего времени столько же сколько программист? Это у Вас так происходит, потому что Вы так работаете. Но это не значит, что это правильно. Разделение труда, вот к чему приходят все так или иначе.
Поймите, очень трудно найти хороших верстальщиков на адекватную зарплату. Приходится брать студентов-школьников о которых Вы так пренебрежительно отзываетесь в статье. Или по вашему кто-то отучившись 5 лет в универе, поучаствовав в десятке проектов идет работать верстальщиком?

[standov]

да, я абсолютно с вами согласен во всем кроме «но она для тех людей которые и программируют и делают верстку»
я не верю в безшовную конвергенцию всего, я получаю от верстальщика XHTML верстку ни больше ни меньше, я уважаю его труд — сам я не способен на такое по причине ориентации на другое — я даже думаю не так, и вот моя задача имея результат работы верстальщика с минимальными моими затратами (читайте с максимальной экономической целесообразностью) привести его верстку в формат доступный фреймворку, cms и т.п., приведя в этот формат и обнаружив вдруг ошибку в верстке (при определенных обстоятельствах этот див налазит на этот) я отдаю результат уже моей работы обратно верстальщику, он правит и я с усилиями равными проверке на «не тронутость» tal разметки реинтегрирую новую версию в конечный продукт — вот она максимальная эффективность в моем понимании, в чем я заблуждаюсь?

[standov]

знаете, я не верю что из верстальщика может получится программист как и из дизайнера и нового направления — фронтенд девелопера и, соответственно, наоборот. я работал с гениальными верстальщиками, гениальными фронтами, гениальными девами — никто не претендует на хлеб друг-друга по причине разного склада ума и разного мышления, я не говорю «лучше-хуже» он просто разный

[aps]

>Или по вашему кто-то отучившись 5 лет в универе,
> поучаствовав в десятке проектов идет работать верстальщиком?
Я например. В основном работаю как верстальщик и фронт-енд программист.
На PHP (до того PERL) программирую только свои собственные проекты, или когда в конторе затык и все программисты заняты. Как сейчас.

[crazyprog]

>Или по вашему кто-то отучившись 5 лет в универе,
> поучаствовав в десятке проектов идет работать верстальщиком?

[crazyprog]

А я лично видел такого человека — вполне адекватную верстку делал. Более того, он учился и работал, закончил институт, еще проработал пол года и ушел в другую контору опять же верстальщиком. Занимался ТОЛЬКО версткой и немного JS.

[xaxoxy]

PHPTAL отличается от XSLT так же, как Smarty от блочных шаблонизаторов.

здесь не используется XSL файл для задания логики.

я бы выделил данный шаблонизатор в отдельную группу шаблонизаторов (TAL).

[meglio]

Абсолютно поддерживаю автора статьи и подтверждаю великолепие PHPTAL.
Сам использую уже несколько лет.