Комментарии 39
Великолепная вещь!!1 А с ORM как прекрасно будет работать.
НЛО прилетело и опубликовало эту надпись здесь
у натива есть 2 огромных минуса:
1. сделанный шаблон (я имею в виду с кодом уже) на доработку верстальщику не вернешь
2. В мешанине html и php сложно ориентироваться — нужная «точка» в TAL шаблоне очень легко находится глазами
1. сделанный шаблон (я имею в виду с кодом уже) на доработку верстальщику не вернешь
2. В мешанине html и php сложно ориентироваться — нужная «точка» в TAL шаблоне очень легко находится глазами
НЛО прилетело и опубликовало эту надпись здесь
1. отнюдь, просто я например не вмешиваюсь в работу верстальщика — я не шарю так как он во всех премудростях и так-же не хочу что-бы он вмешивался в мою работу — вот тут разделение и рулит
2. да как не смешай, сейчас один из проектов на ZF c нативными шаблонами, когда перехожу на тал в других проектах — отдыхаю душой и телом, попробуйте.
2. да как не смешай, сейчас один из проектов на ZF c нативными шаблонами, когда перехожу на тал в других проектах — отдыхаю душой и телом, попробуйте.
Т. е. после вставки инструкций 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>
Что вы думаете по этому поводу?
Интересная штука :)
Когда смотрел PHPTAL появилось стойкое ощущение упрощённой lightweight версии XSLT. :) А так отличная штука.
Шаг.1 Нативный php
Шаг.2 Нативный php заменяются на {макросы}
Шаг.3 {макросы} заменяются на XML
…
Когда php-программисты дойдут до логического конца?
Шаг.2 Нативный php заменяются на {макросы}
Шаг.3 {макросы} заменяются на XML
…
Когда php-программисты дойдут до логического конца?
а какой конец? XML+XSLT дык дошли и прошли, затык в производительности и цене XSLT специалиста
>затык в производительности и цене
И то и другое так часто обсуждалось, что как-то даже неинтересно.
Лучше всего здесь habrahabr.ru/blogs/about_cms/22018/ (Дискуссия разработчиков UMI и Bitrix)
>а какой конец? XML+XSLT
Я вас за язык не тянул :)
И то и другое так часто обсуждалось, что как-то даже неинтересно.
Лучше всего здесь habrahabr.ru/blogs/about_cms/22018/ (Дискуссия разработчиков UMI и Bitrix)
>а какой конец? XML+XSLT
Я вас за язык не тянул :)
я говорю о своем опыте а в приведенной вами статье человек пишет маркетинговые лозунги не подтверждая фактами.
В общем, если вас устраивает XSLT — замечательно, технология действительно мощная но я для view его применить успешно не смог.
В общем, если вас устраивает XSLT — замечательно, технология действительно мощная но я для view его применить успешно не смог.
Как-то не заметил маркетинговых лозунгов. Да и смысла упираться Котыреву нет. В его UMI кроме XSLT имеет традиционный шаблонизатор.
Вопрос с производительностью — не вопрос при правильной архитектуре проекта.
Вопрос с кадрами — не знаю. Мои наблюдения совпадают с котыревскими. За месяц нормального верстальщика вполне можно обучить работать с XSLT на более-менее приемлемом уровне.
Вопрос с производительностью — не вопрос при правильной архитектуре проекта.
Вопрос с кадрами — не знаю. Мои наблюдения совпадают с котыревскими. За месяц нормального верстальщика вполне можно обучить работать с XSLT на более-менее приемлемом уровне.
мои наблюдения не совпадают, для вещей в которых xslt имеет преимущества (ключи и группировки) вы верстальщика и за 6 месяцев не обучите поскольку это чистой воды программинг — он уволится. а без этого юзать xslt с предварительным преобразованием данных в XML — это как-то не оправдано мне кажется.
Для меня тал это как-раз та золотая середина — почти xslt только без XML преобразования и «лишних» и навороченных штук
Для меня тал это как-раз та золотая середина — почти xslt только без XML преобразования и «лишних» и навороченных штук
Может вы и правы. На хабре каждый второй «девелопер» выступает за неподдержку IE6. Таким уродцам за полгода ключи действительно не освоить. Просто мне везло с верстальщиками.
угу, меня — программера по сути и, как я считаю, достаточно опытного :) при словах «группировка Мюнча» начинает типать, группировка описание которой в хорошей книге сопровождается словами «вы все равно не поймете, поэтому просто запомните» осваивать верстальщику.
Объем достойной книги по технологии XSLT порядка 800 страниц и все эти 800 засалены поскольку постоянно к ним обращаешься — вот мой опыт общения с XSLT, очень красиво, чертовски мощно но также и тяжело для хорошего понимания.
Объем достойной книги по технологии XSLT порядка 800 страниц и все эти 800 засалены поскольку постоянно к ним обращаешься — вот мой опыт общения с XSLT, очень красиво, чертовски мощно но также и тяжело для хорошего понимания.
>при словах «группировка Мюнча» начинает типать
А меня всякий раз, когда приходится учить очередной шаблонизатор, который «намного лучше Smarty» :)
Но метод Мюнха я действительно просто вызубрил наизусть. Правда не помню, когда последний раз его использовал.
А меня всякий раз, когда приходится учить очередной шаблонизатор, который «намного лучше Smarty» :)
Но метод Мюнха я действительно просто вызубрил наизусть. Правда не помню, когда последний раз его использовал.
вот я так не могу, если я чего-то не понимаю в том что использую — плохо сплю, я согласен про новый шаблонизатор, я никого не призываю пересаживаться особенно если все устраивает, это скорее для тех кто в поиске либо кто подыскивает технологию для фреймворка, cms как я когда-то.
>я никого не призываю пересаживаться
Тут дело не в насильной пересадке, а в том что нет единого стандарта. В каждой команде php-разработчиков свои вкусы, в каждой CMS свой шаблонизатор.
Поэтому и зверею и спасение вижу только в общепринятом стандарте.
Накладные расходы конечно есть. Но при миграции верстальщика (а я >11 лет верстаю) лучше иметь под рукой стандарт.
Тут дело не в насильной пересадке, а в том что нет единого стандарта. В каждой команде php-разработчиков свои вкусы, в каждой CMS свой шаблонизатор.
Поэтому и зверею и спасение вижу только в общепринятом стандарте.
Накладные расходы конечно есть. Но при миграции верстальщика (а я >11 лет верстаю) лучше иметь под рукой стандарт.
полностью согласен, для меня именно этот шаблонизатор привлекателен еще и тем что это тоже почти стандарт :)
Zope это почти икона (пусть и не очень удачным названием :)) — wiki.zope.org/ZPT/TALSpecification14
Zope это почти икона (пусть и не очень удачным названием :)) — wiki.zope.org/ZPT/TALSpecification14
>именно этот шаблонизатор привлекателен еще и тем что
>еще и тем что это тоже почти стандарт
И приверженцы Smarty такого же мнения, и у любого другого также 1000 аргументов. А стандарт то только один. И только он включен в PHP5+
>Zope это почти икона
Первый раз я сталкнулся (в качестве верстальщика) с XSLT на Java проекте. Основательно выучил на .NET А уж потом на своих собственных PHP-проектах внедрил.
Вряд ли я единственный кому приходится мигрировать из команды в команду. И работать в нескольуих средах параллельно. Как бы хорош не был Tal — это при таком раскладе не выход.
Я начал с того что все идет к логическому концу. Оно к нему и придет.
Бардак в области разработок среди php-программистов рано или поздно закончится. Придут к единому стандарту. Или двум-трем :)
>еще и тем что это тоже почти стандарт
И приверженцы Smarty такого же мнения, и у любого другого также 1000 аргументов. А стандарт то только один. И только он включен в PHP5+
>Zope это почти икона
Первый раз я сталкнулся (в качестве верстальщика) с XSLT на Java проекте. Основательно выучил на .NET А уж потом на своих собственных PHP-проектах внедрил.
Вряд ли я единственный кому приходится мигрировать из команды в команду. И работать в нескольуих средах параллельно. Как бы хорош не был Tal — это при таком раскладе не выход.
Я начал с того что все идет к логическому концу. Оно к нему и придет.
Бардак в области разработок среди php-программистов рано или поздно закончится. Придут к единому стандарту. Или двум-трем :)
Что-то у меня сомнения, что он генерирует хороший php на выходе, тут эти теги в код так просто не преобразуешь. И да, синтаксис адский.
Меня зацепили Ваши слова, Ваш верстальщик не школьник.
В защиту верстальщиков-школьников.
По моему глубокому убеждению верстку должны делать верстальщики, а программировать программисты. Поэтому вопрос, standov, вы написали это статью как верстальщик или программист??? Вы же сделали не один шаблон, поэтому должны понимать и тех и других.
Я понимаю что Вам нравиться эта технология, но она для тех людей которые и программируют и делают верстку. А это экономически не правильно. Попробую объяснить почему я так считаю.
Точно так же как есть ModelViewController, есть ДизайнВерсткаПрограммирование и именно верстка это наименее оплачиваемая часть. Или Вы хотите, что бы верстальщик получал за час своего времени столько же сколько программист? Это у Вас так происходит, потому что Вы так работаете. Но это не значит, что это правильно. Разделение труда, вот к чему приходят все так или иначе.
Поймите, очень трудно найти хороших верстальщиков на адекватную зарплату. Приходится брать студентов-школьников о которых Вы так пренебрежительно отзываетесь в статье. Или по вашему кто-то отучившись 5 лет в универе, поучаствовав в десятке проектов идет работать верстальщиком?
В защиту верстальщиков-школьников.
По моему глубокому убеждению верстку должны делать верстальщики, а программировать программисты. Поэтому вопрос, standov, вы написали это статью как верстальщик или программист??? Вы же сделали не один шаблон, поэтому должны понимать и тех и других.
Я понимаю что Вам нравиться эта технология, но она для тех людей которые и программируют и делают верстку. А это экономически не правильно. Попробую объяснить почему я так считаю.
Точно так же как есть ModelViewController, есть ДизайнВерсткаПрограммирование и именно верстка это наименее оплачиваемая часть. Или Вы хотите, что бы верстальщик получал за час своего времени столько же сколько программист? Это у Вас так происходит, потому что Вы так работаете. Но это не значит, что это правильно. Разделение труда, вот к чему приходят все так или иначе.
Поймите, очень трудно найти хороших верстальщиков на адекватную зарплату. Приходится брать студентов-школьников о которых Вы так пренебрежительно отзываетесь в статье. Или по вашему кто-то отучившись 5 лет в универе, поучаствовав в десятке проектов идет работать верстальщиком?
да, я абсолютно с вами согласен во всем кроме «но она для тех людей которые и программируют и делают верстку»
я не верю в безшовную конвергенцию всего, я получаю от верстальщика XHTML верстку ни больше ни меньше, я уважаю его труд — сам я не способен на такое по причине ориентации на другое — я даже думаю не так, и вот моя задача имея результат работы верстальщика с минимальными моими затратами (читайте с максимальной экономической целесообразностью) привести его верстку в формат доступный фреймворку, cms и т.п., приведя в этот формат и обнаружив вдруг ошибку в верстке (при определенных обстоятельствах этот див налазит на этот) я отдаю результат уже моей работы обратно верстальщику, он правит и я с усилиями равными проверке на «не тронутость» tal разметки реинтегрирую новую версию в конечный продукт — вот она максимальная эффективность в моем понимании, в чем я заблуждаюсь?
я не верю в безшовную конвергенцию всего, я получаю от верстальщика XHTML верстку ни больше ни меньше, я уважаю его труд — сам я не способен на такое по причине ориентации на другое — я даже думаю не так, и вот моя задача имея результат работы верстальщика с минимальными моими затратами (читайте с максимальной экономической целесообразностью) привести его верстку в формат доступный фреймворку, cms и т.п., приведя в этот формат и обнаружив вдруг ошибку в верстке (при определенных обстоятельствах этот див налазит на этот) я отдаю результат уже моей работы обратно верстальщику, он правит и я с усилиями равными проверке на «не тронутость» tal разметки реинтегрирую новую версию в конечный продукт — вот она максимальная эффективность в моем понимании, в чем я заблуждаюсь?
знаете, я не верю что из верстальщика может получится программист как и из дизайнера и нового направления — фронтенд девелопера и, соответственно, наоборот. я работал с гениальными верстальщиками, гениальными фронтами, гениальными девами — никто не претендует на хлеб друг-друга по причине разного склада ума и разного мышления, я не говорю «лучше-хуже» он просто разный
>Или по вашему кто-то отучившись 5 лет в универе,
> поучаствовав в десятке проектов идет работать верстальщиком?
Я например. В основном работаю как верстальщик и фронт-енд программист.
На PHP (до того PERL) программирую только свои собственные проекты, или когда в конторе затык и все программисты заняты. Как сейчас.
> поучаствовав в десятке проектов идет работать верстальщиком?
Я например. В основном работаю как верстальщик и фронт-енд программист.
На PHP (до того PERL) программирую только свои собственные проекты, или когда в конторе затык и все программисты заняты. Как сейчас.
>Или по вашему кто-то отучившись 5 лет в универе,
> поучаствовав в десятке проектов идет работать верстальщиком?
> поучаствовав в десятке проектов идет работать верстальщиком?
PHPTAL отличается от XSLT так же, как Smarty от блочных шаблонизаторов.
здесь не используется XSL файл для задания логики.
я бы выделил данный шаблонизатор в отдельную группу шаблонизаторов (TAL).
здесь не используется XSL файл для задания логики.
я бы выделил данный шаблонизатор в отдельную группу шаблонизаторов (TAL).
Абсолютно поддерживаю автора статьи и подтверждаю великолепие PHPTAL.
Сам использую уже несколько лет.
Сам использую уже несколько лет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Иной — PHPTAL