Comments 68
«Я не хочу сделать из Twig универсальный шаблонизатор для PHP, далеко от этого.» — где логика, причем там ", далеко от этого"? Переводил через Гугл транслейт?
Поработай на орфографией:
… согласен с большинствоим из них. Сейчас…
… несколько месяцв назад…
… хорошие нвоости в том что…
… представил компонет шаблонов…
… если вы считате что мои аргументы…
… найти компромис в наличии… компромисс с 2 «С»
… говорил в предыдщем посте, язык…
и так далее… очень много ошибок!
Поработай на орфографией:
… согласен с большинствоим из них. Сейчас…
… несколько месяцв назад…
… хорошие нвоости в том что…
… представил компонет шаблонов…
… если вы считате что мои аргументы…
… найти компромис в наличии… компромисс с 2 «С»
… говорил в предыдщем посте, язык…
и так далее… очень много ошибок!
Гугл транслейт не вставил бы опечаток :)
Перед публикованием полтора раза перечитал текст, видать уже глаз замылился.
Перед публикованием полтора раза перечитал текст, видать уже глаз замылился.
>в комментариях, и, по-просту, согласен с большинством
>шаблонизатор на читом PHP и имеющий
> (прим. русская версия), подумате еще раз.
>относится к логике предствления. И, конечно, простые условия и циклы это часть логики предствления.
> И этот кусок кода для меня полносью непреемлем:
>это также вопрос стандратизации кода:
> для меня является лучшим копромиссом, плюс то что
Хинт: Встроенный спелл-чекер файерфокса все эти ошибки подсветил и почти везде предложил корректные варианты исправления. Еще много похожих ошибок, но пока некогда
>шаблонизатор на читом PHP и имеющий
> (прим. русская версия), подумате еще раз.
>относится к логике предствления. И, конечно, простые условия и циклы это часть логики предствления.
> И этот кусок кода для меня полносью непреемлем:
>это также вопрос стандратизации кода:
> для меня является лучшим копромиссом, плюс то что
Хинт: Встроенный спелл-чекер файерфокса все эти ошибки подсветил и почти везде предложил корректные варианты исправления. Еще много похожих ошибок, но пока некогда
Да, по поводу стилистики текста, корректности перевода и общей читаемости — это мой второй перевод и может хоть здесь скажут что то, что я написал читать невозможно и пора бы перестать этим заниматься? :)
Делай перевод своими словами, что бы он был максимально простым и понятным, а также добавляй картинок, ибо текст «в сухомятку» не очень идёт
Читать возможно, хотя многие ошибки (орфография и пунктуация) бросаются в глаза. В оформлении мешают читать примечания переводчика и куски оригинального текста без выделения, обычно их как-то оформляют, чтоб в глаза не бросались, курсивом, например. Но это придирки уже наверное, опечатки (надеюсь ;) ) и запятые — больше всего мешают. Причём большинство опечаток выявляются практически любым спелл-чекером. С запятыми сложнее — знаю только одну программу, которая хоть как-то пытается обнаружить и исправить ошибки пунктуации, но рекомендовать ее не могу, ибо закрытая, платная (хотя сейчас бета версия ее очередного релиза доступна бесплатно )и только под одну (или две, под Маком не работал в ней) платформу.
P.S. И, по-моему, не стоит в публикациях употреблять сокращения «т. к.», «т. е.» и т. д., и т. п. :) Ведь не конспект для себя, и не холивар в комментах ;)
P.S. И, по-моему, не стоит в публикациях употреблять сокращения «т. к.», «т. е.» и т. д., и т. п. :) Ведь не конспект для себя, и не холивар в комментах ;)
UFO just landed and posted this here
Песочница — абсолютно бесполезный режим. Если вы вдруг решили сделать огромного блогомонстра с возможностью своих шаблонов, по такому случаю можно и свое что-нибудь, причем желательно синтаксис брать с какой-нибудь существующей блогосистемы.
А если цмс, и клиент хочет править шаблоны, но нет желания постоянно выяснять что он там сломал?
UFO just landed and posted this here
1) Клиент неадекват, с ним все равно ничего хорошего не выйдет
2) А при чем тут sandbox? Sandbox предполагает защиту от выполнения подсунутого злоюзерами кода, а клиент вряд ли будет пытаться взломать собственный сайт :)
2) А при чем тут sandbox? Sandbox предполагает защиту от выполнения подсунутого злоюзерами кода, а клиент вряд ли будет пытаться взломать собственный сайт :)
1) клиент предпочитает заплатить один раз, а не вызывать разработчика по каждому чиху — это неадекват?
2) необязательно попытка взлома нужна, чтоб обрушить систему — «не ищите злого умысла, там где действия можно объяснить простой глупостью» (почти с) не помню кто
2) необязательно попытка взлома нужна, чтоб обрушить систему — «не ищите злого умысла, там где действия можно объяснить простой глупостью» (почти с) не помню кто
UFO just landed and posted this here
Согласен, как правило так и случается.
Хорошо, еще один пример из жизни: клиент хочет предоставить владельцам платных акканутов возможность редактировать шаблоны их персональных страниц (назовем это так). Т. е. шаблоны должны редактировать непосредственно пользователи сайта. Выходов может быть несколько — писать свой язык шаблонов под эти узкие нужды или использовать некий, жутко урезаный, режим песочницы.
Хорошо, еще один пример из жизни: клиент хочет предоставить владельцам платных акканутов возможность редактировать шаблоны их персональных страниц (назовем это так). Т. е. шаблоны должны редактировать непосредственно пользователи сайта. Выходов может быть несколько — писать свой язык шаблонов под эти узкие нужды или использовать некий, жутко урезаный, режим песочницы.
UFO just landed and posted this here
Может быть потому, что xslt в приведенном списке шаблонизаторов не совсем уместен?.. =)
UFO just landed and posted this here
>xslt в приведенном списке шаблонизаторов не совсем уместен?..
В прринципе да. Стандарт, поддерживаемый во всех современнвх платформах, включая PHP и разнообразные самопальные библиотеки, которым нет числа, и которые порождают холивары уже много лет, никак не укладываются в один ряд.
В прринципе да. Стандарт, поддерживаемый во всех современнвх платформах, включая PHP и разнообразные самопальные библиотеки, которым нет числа, и которые порождают холивары уже много лет, никак не укладываются в один ряд.
Согласитесь, что пресловутый порог вхождения в XSLT довольно высокий, а в PHP традиционно низкий, как и у большинства (со всеми не знаком, может и у всех) шаблонизаторов из списка? И это не учитывая совершенно разные парадигмы языков.
Если XML+XSLT жестко прикрутить к PHP, как единственный способ вывода HTML и пр., то, сдаётся мне, популярность PHP среди начинающих веб-разработчиков резко пойдёт на убыль, но вот росту популярности XSLT это вряд ли поспособствует.
Если XML+XSLT жестко прикрутить к PHP, как единственный способ вывода HTML и пр., то, сдаётся мне, популярность PHP среди начинающих веб-разработчиков резко пойдёт на убыль, но вот росту популярности XSLT это вряд ли поспособствует.
Имхо очень большое имхо, если не глубоко не копать и применять предельно тупой XSLT-стиль (3-4 основных инструкции) он не сложнее Smarty. И уж точно проще PHP.
Кстати если сравнивать по сложности стандарты+баги+фичи CSS, JS и XSLT, последний выглядит достаточно прозрачным и простым. Я плохо понимаю почему верстальщику, который смог выучить 10-15 багов ie6 + Opera + FF сложно выучить азы XSLT.
Наверное потому, что XSLT не является шаблонизатором в том смысле, который автор поста вкладывает в это слово, или просто не отвечает его критериям:
— краткость — по-моему к достоинствам XSLT это сложно отнести ;) не говоря уж о том, что данные для XSLT надо готовить специально. Причем удобным способом мне представляется для этого использование шаблонизаторов :), так как по сути их назначение — легко перевести структуры данных PHP в текстовые форматы, такие как HTML и XML
— синтаксис, ориентированный на шаблоны — тут, мне кажется, XML (любой) плохо подходит, ведь любая реализация языка шаблонов будет накладываться поверх синтаксиса собственно XML.
— повторное использование (прежде всего в смысле объектно-ориентированного наследования) — повторное использование есть, но мне оно показалось жутко неудобным
— режим «песочницы» — честно говоря, так и не понял толком что это и можно ли, — и нужно ли, — реализовывать это на XSLT.
Внутреннее представление данных в XML и преобразование их во внешнее с помощью XSLT — мощная и универсальная технология, но вряд ли имеет смысл использовать её для простых задач, типа выдачи данных из нескольких SQL запросов в двух-трех однотипных представлениях. Не говоря уж о том, что порог вхождения для верстальщика (да и программиста, привыкшего к императивным языкам) очень высок.
— краткость — по-моему к достоинствам XSLT это сложно отнести ;) не говоря уж о том, что данные для XSLT надо готовить специально. Причем удобным способом мне представляется для этого использование шаблонизаторов :), так как по сути их назначение — легко перевести структуры данных PHP в текстовые форматы, такие как HTML и XML
— синтаксис, ориентированный на шаблоны — тут, мне кажется, XML (любой) плохо подходит, ведь любая реализация языка шаблонов будет накладываться поверх синтаксиса собственно XML.
— повторное использование (прежде всего в смысле объектно-ориентированного наследования) — повторное использование есть, но мне оно показалось жутко неудобным
— режим «песочницы» — честно говоря, так и не понял толком что это и можно ли, — и нужно ли, — реализовывать это на XSLT.
Внутреннее представление данных в XML и преобразование их во внешнее с помощью XSLT — мощная и универсальная технология, но вряд ли имеет смысл использовать её для простых задач, типа выдачи данных из нескольких SQL запросов в двух-трех однотипных представлениях. Не говоря уж о том, что порог вхождения для верстальщика (да и программиста, привыкшего к императивным языкам) очень высок.
Применять xslt, на мой взгляд, уместно если в таком случае: дали верстальщику на верстку, но с выбором серверного языка программирования не определились.
UFO just landed and posted this here
> Pear и Zend достаточно серьезные проекты, поэтому у них были причины запретить короткие теги, не так ли?
Возможно. А возможно и не было. Причины против названы смешные: невозможно работать с XML через задницу(лапшой из XML+PHP) и недостаточная портируемость(если кто-то специально отключит его и запретит .htaccess(для апача)).
Обе причины явно надуманы.
Что касается экранирования, то на практике ситуаций. где экранировать не надо — немногим меньше тех, где надо. Поэтому верстальщик шаблонов САМ должен расставлять нужное.
Возможно. А возможно и не было. Причины против названы смешные: невозможно работать с XML через задницу(лапшой из XML+PHP) и недостаточная портируемость(если кто-то специально отключит его и запретит .htaccess(для апача)).
Обе причины явно надуманы.
Что касается экранирования, то на практике ситуаций. где экранировать не надо — немногим меньше тех, где надо. Поэтому верстальщик шаблонов САМ должен расставлять нужное.
>с XML через задницу(лапшой из XML+PHP)
По-моему использование PHP как шаблонизатора для генерации xHTML страниц (и любых других XML представлений), как раз и представляет собой «лапшу» из XML+PHP. Или XML код надо генерировать через echo "<a href="#">".$var."</a>?
>если кто-то специально отключит его
В php.ini short_open_tag отключены (давно?) при установке, надо его править ручками, чтобы включить.
По-моему использование PHP как шаблонизатора для генерации xHTML страниц (и любых других XML представлений), как раз и представляет собой «лапшу» из XML+PHP. Или XML код надо генерировать через echo "<a href="#">".$var."</a>?
>если кто-то специально отключит его
В php.ini short_open_tag отключены (давно?) при установке, надо его править ручками, чтобы включить.
>По-моему использование PHP как шаблонизатора для генерации xHTML страниц
Это исключение, которое обходится элементарным хаком из нескольки символов, которые мы все знаем, и на проект нужно лишь пару раз.
Если откажетесь от хака в несколько символов в 1 месте — аналогичное кол-во символов придется писать при каждой переменной в шаблоне. Что не выгодно.
> В php.ini short_open_tag отключены (давно?) при установке, надо его править ручками, чтобы включить.
При установке все зависит от дистрибуции ;) У меня по умолчанию работает.
Это исключение, которое обходится элементарным хаком из нескольки символов, которые мы все знаем, и на проект нужно лишь пару раз.
Если откажетесь от хака в несколько символов в 1 месте — аналогичное кол-во символов придется писать при каждой переменной в шаблоне. Что не выгодно.
> В php.ini short_open_tag отключены (давно?) при установке, надо его править ручками, чтобы включить.
При установке все зависит от дистрибуции ;) У меня по умолчанию работает.
>Это исключение, которое обходится элементарным хаком из нескольки символов, которые мы все знаем
Это мы знаем, но а верстальщик может и не знать. Как минимум, это исключение нужно будет документировать, а кто-нибудь, как всегда бывает, не заметит строчку в документации :( Ну или при личном обучении я могу забыть это сказать верстальщику.
>При установке все зависит от дистрибуции ;) У меня по умолчанию работает.
Не спорю, но 3 используемых мною способа (вининсталлер и сборка из сорцов с php.net, установка из репа убунту) дают один результат
Это мы знаем, но а верстальщик может и не знать. Как минимум, это исключение нужно будет документировать, а кто-нибудь, как всегда бывает, не заметит строчку в документации :( Ну или при личном обучении я могу забыть это сказать верстальщику.
>При установке все зависит от дистрибуции ;) У меня по умолчанию работает.
Не спорю, но 3 используемых мною способа (вининсталлер и сборка из сорцов с php.net, установка из репа убунту) дают один результат
Верстальщик должен знать свой инструмент.
PHP на уровне инструмента для верстки учится за час. В том числе и с этим хаком, про который не надо забыть рассказать. Тем более что вертальщику надо отдать шаблоны, сделанные программистом(ага, черные буквы на белом фоне), которые он и будет изучать, чтобы понять, что надо выводить.
По поводу настройки php.ini — на все воля админа. А как админу что настраивать говорит программист(флаги и параметры пхп, нужные модули и т.д.)
PHP на уровне инструмента для верстки учится за час. В том числе и с этим хаком, про который не надо забыть рассказать. Тем более что вертальщику надо отдать шаблоны, сделанные программистом(ага, черные буквы на белом фоне), которые он и будет изучать, чтобы понять, что надо выводить.
По поводу настройки php.ini — на все воля админа. А как админу что настраивать говорит программист(флаги и параметры пхп, нужные модули и т.д.)
А я бы не рискнул доверить PHP верстальщику…
Как перешел на XSLT, понял, что с другими шаблонизаторами работать больше не могу. Если программизм серьезный, то идеальный вариант такой: программисты выдают XML где все данные подготовлены и представлены в нужном виде, и им абсолютно все равно, что с этими данными будут делать верстальщики.
Моя практика показывает, что верстальщику намного проще освоить xsl, чем php. Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
Как перешел на XSLT, понял, что с другими шаблонизаторами работать больше не могу. Если программизм серьезный, то идеальный вариант такой: программисты выдают XML где все данные подготовлены и представлены в нужном виде, и им абсолютно все равно, что с этими данными будут делать верстальщики.
Моя практика показывает, что верстальщику намного проще освоить xsl, чем php. Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
>Если программизм серьезный, то идеальный вариант такой
У идеала всё хорошо, кроме того, что в реальной жизни не встречается, увы.
>Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
Может отсюда растут ноги у легенд (судя по комментам) о громоздкости и медлительности XSLT-кода? Когда, только познакомившись с XSLT, я горел энтузиазмом и сделал пару рабочих сайтов «на уровне», то был неприятно удивлён этой самой громоздкостью и медлительностью (про скорость разработки скромно промолчу :) ). Потом, через довольно большое время, познакомился с человеком, занимавшимся XSLT серьезно несколько лет, поспорили с ним, в общем за ночь (причем не в очень трезвом состоянии :) ) он выдал XSLT файлы раза в 3 меньше по размеру чем мои и раз в 5 быстрее. Да еще ругался на мой XML, говорил, что при грамотном XML еще процентов 20 можно было бы «вытащить». То есть по сути XML+XSLT примерно оказались равны по скорости Smarty, чуть больше по размеру, намного элегантнее (имхо), но… мои Smarty шаблоны были написаны примерно за то же время, что и XSLT, хотя изучал я его несколько часов, а не несколько лет.
P.S. После того случая перешёл на native PHP шаблоны :)
У идеала всё хорошо, кроме того, что в реальной жизни не встречается, увы.
>Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
Может отсюда растут ноги у легенд (судя по комментам) о громоздкости и медлительности XSLT-кода? Когда, только познакомившись с XSLT, я горел энтузиазмом и сделал пару рабочих сайтов «на уровне», то был неприятно удивлён этой самой громоздкостью и медлительностью (про скорость разработки скромно промолчу :) ). Потом, через довольно большое время, познакомился с человеком, занимавшимся XSLT серьезно несколько лет, поспорили с ним, в общем за ночь (причем не в очень трезвом состоянии :) ) он выдал XSLT файлы раза в 3 меньше по размеру чем мои и раз в 5 быстрее. Да еще ругался на мой XML, говорил, что при грамотном XML еще процентов 20 можно было бы «вытащить». То есть по сути XML+XSLT примерно оказались равны по скорости Smarty, чуть больше по размеру, намного элегантнее (имхо), но… мои Smarty шаблоны были написаны примерно за то же время, что и XSLT, хотя изучал я его несколько часов, а не несколько лет.
P.S. После того случая перешёл на native PHP шаблоны :)
> У идеала всё хорошо, кроме того, что в реальной жизни не встречается, увы.
Мне кажется, именно так сделали в яндексе. Не думаю, что XSLT там используется только из-за разных форм вывода одной информации (хотя и это тоже). Есть еще много крупных проектов, разные части которых написаны на разных языках. Сам на одном из таких работал. Если верстка и программинг разделены, то это вообще никого не парит.
Про ваш случай… Да, тут тонкий момент. Чтобы писать на смарти, достаточно его поизучать пару часов. Чтобы писать на XSLT хорошо, его надо полюбить) А плохо на XSLT лучше вообще не писать. Это будет медленно, некрасиво и только пополнит ряды ненавистников этой технологии. Впрочем, это относится не только к XSLT…
Мне кажется, именно так сделали в яндексе. Не думаю, что XSLT там используется только из-за разных форм вывода одной информации (хотя и это тоже). Есть еще много крупных проектов, разные части которых написаны на разных языках. Сам на одном из таких работал. Если верстка и программинг разделены, то это вообще никого не парит.
Про ваш случай… Да, тут тонкий момент. Чтобы писать на смарти, достаточно его поизучать пару часов. Чтобы писать на XSLT хорошо, его надо полюбить) А плохо на XSLT лучше вообще не писать. Это будет медленно, некрасиво и только пополнит ряды ненавистников этой технологии. Впрочем, это относится не только к XSLT…
Для крупных проектов, с кучей разных платформ, унаследованных сервисов (которые уже никто не помнит как работают :) ), плановое переписывание критических участков на других языках и т. д., XML+XSLT, наверное, оптимальный вариант. Но вот для задач типа визитки, хомяка, блога, форума, галереи и т. п., с кодами которых работают максимум 2-3 человека, XSLT подойдёт только если уметь на нем писать хорошо, что значит его любить ;) Причём любовь бывает разная, я вот его люблю, как люблю какую-нить актрису — приятно иногда посмотреть ;) PHP шаблоны (да и вообще язык) тоже люблю, как любят некрасивую, сварливую и вроде даже надоевшую, но свою жену :) Сейчас вот еще пытаюсь любовницу завести (Python и Django) :D
Мой верстальщик освоил шаблоны на пхп с первого раза. Это заняло минут 15 объяснений со всеми тонкостями. Правда она умеет программировать на C++)
Что и требовалось доказать — императивный подход куда проще для освоения :)
Между понятиями «проще в освоении» и «мощнее и проще в использовании» я выберу однозначно второе.
Рассмотрим предельные случаи? :) И, опять-таки, в чём мощь? Насколько я знаю основные доводы в пользу XSLT:
— кросс… (платформенный, языковой, еще черти-какой :) ) стандарт
— как следствие, поддержка основными продуктами от клиентских приложений до серверных СУБД
— «идеологические» вещи, такие как полное отделение кода от данных, а данных от представления, и что немаловажно без костылей типа {% foreach… %} (хотя похожие костыли вроде есть и в XTML, по крайней мере для PHP).
— как следствие, более четкое разделение обязанностей в команде и облегчение развития и поддержки
— даже какая-то красота и элегантность решения (в принципе, самой идеи, конкретную реализацию в виду не имею :) )
— возможно даже большая скорость разработки (при должном уровне знаний и опыта, потому «возможно», утверждать не имею права, скорее обратное :) ) и с нуля, и правки, включая полную переделку (а фреймворки XSLT есть? по типу CSS)
Но вот «мощь» как таковая, чтоб парой строк решить задачу для которой в других шаблонах понадобится десятки строк кода, особенно в решениях, которые заведомо не будут ни расширяться, ни мигрировать на другую платформу, ни изменять формат данных… в общем решающих конкретную задачу по преобразованию PHP-данных в HTML-код «здесь и сейчас» — не вижу я её, а ведь это, пожалуй, самая распространенная задача в веб-программировании (по числу «инсталяций» :) )
— кросс… (платформенный, языковой, еще черти-какой :) ) стандарт
— как следствие, поддержка основными продуктами от клиентских приложений до серверных СУБД
— «идеологические» вещи, такие как полное отделение кода от данных, а данных от представления, и что немаловажно без костылей типа {% foreach… %} (хотя похожие костыли вроде есть и в XTML, по крайней мере для PHP).
— как следствие, более четкое разделение обязанностей в команде и облегчение развития и поддержки
— даже какая-то красота и элегантность решения (в принципе, самой идеи, конкретную реализацию в виду не имею :) )
— возможно даже большая скорость разработки (при должном уровне знаний и опыта, потому «возможно», утверждать не имею права, скорее обратное :) ) и с нуля, и правки, включая полную переделку (а фреймворки XSLT есть? по типу CSS)
Но вот «мощь» как таковая, чтоб парой строк решить задачу для которой в других шаблонах понадобится десятки строк кода, особенно в решениях, которые заведомо не будут ни расширяться, ни мигрировать на другую платформу, ни изменять формат данных… в общем решающих конкретную задачу по преобразованию PHP-данных в HTML-код «здесь и сейчас» — не вижу я её, а ведь это, пожалуй, самая распространенная задача в веб-программировании (по числу «инсталяций» :) )
И что, что стандарт? Аналоги шаблонов типа PHP есть в любом ЯП и разница лишь в синтаксисе, котоорый элементарен.
Минус в наглядности. Набор правил как правило не нагляден.
> без костылей типа {% foreach… %}
Это не костыль, а логика отображения. Не стоит называть альтернативную вещь костылем, если она не хуже.
Я ничего не имею против XSLT, но кроме плюсов у него есть и минусы. Иначе бы его все юзали ;)
Минус в наглядности. Набор правил как правило не нагляден.
> без костылей типа {% foreach… %}
Это не костыль, а логика отображения. Не стоит называть альтернативную вещь костылем, если она не хуже.
Я ничего не имею против XSLT, но кроме плюсов у него есть и минусы. Иначе бы его все юзали ;)
Что-то я не понял, о чем мы спорим :) Видимо фразу «Между понятиями «проще в освоении» и «мощнее и проще в использовании» я выберу однозначно второе», я понял неправильно, как однозначный довод в пользу XSLT. Отсюда и «костыль» — обычный довод и «трупехепешников», не терпящих никаких шаблонизаторов, кроме «великого и могучего», и любителей другого «великого и могучего» :)
Всё не так))
Во-первых, в XSLT есть вполне себе for-each, и есть много народу, которые пытаются на нём (на XSLT) программировать. Думаю, это не основное применение языка)
По поводу универсальности тоже можно поспорить. Когда объем данных большой, XSLT становится ощутимым тормозом. Например, подробный годовой отчет с кучей параметров с детализацией по дням.
XSLT настолько прост и изящен, что многие мои знакомые программисты, увидев его, стали его использовать его во всех проектах, даже в хомяках.
Попытайтесь встать на точку зрения не-программиста (верстальщика) и сравните 2 конструкции:
<?
foreach ($items as $item) {
echo "* {$item}\n";
}
?>
и
<xsl:template match='item'>
… красивый html-like код без страшных конструкций
</xsl:template>
<xsl:apply-templates select='item'/>
Во-первых, в XSLT есть вполне себе for-each, и есть много народу, которые пытаются на нём (на XSLT) программировать. Думаю, это не основное применение языка)
По поводу универсальности тоже можно поспорить. Когда объем данных большой, XSLT становится ощутимым тормозом. Например, подробный годовой отчет с кучей параметров с детализацией по дням.
XSLT настолько прост и изящен, что многие мои знакомые программисты, увидев его, стали его использовать его во всех проектах, даже в хомяках.
Попытайтесь встать на точку зрения не-программиста (верстальщика) и сравните 2 конструкции:
<?
foreach ($items as $item) {
echo "* {$item}\n";
}
?>
и
<xsl:template match='item'>
… красивый html-like код без страшных конструкций
</xsl:template>
<xsl:apply-templates select='item'/>
Вот я тоже считал его простым и изящным, пока не попытался натянуть на существующий сайт :( Вся красота и изящество куда-то резко пропали, когда пришлось пришлось писать километровые XPath (часто, кстати, забывают, что еще и XPath нужно знать, а не только собственно XSLT) в десятиэтажной вложенности шаблонах, чтобы выцепить именно нужный item из десятка других.
P.S. Смотреть страшно на PHP код, специально для контраста? ;) Такой как-то красивее (правда ради красоты пришлось принципами пожертвовать, которые в соседнем треде утверждал :) ):
P.P.S. Что-то я совсем XSLT забыл, не могу понять а где в коде без страшных конструкций собственно значение item выводится?
P.S. Смотреть страшно на PHP код, специально для контраста? ;) Такой как-то красивее (правда ради красоты пришлось принципами пожертвовать, которые в соседнем треде утверждал :) ):
<? foreach $item in $items: ?>
* <?=$item;?>
<? endforeach; ?>
P.P.S. Что-то я совсем XSLT забыл, не могу понять а где в коде без страшных конструкций собственно значение item выводится?
Вредные привычки завсегда усваиваются проще чем полезные :)
Извините, но это явно перебор: Зачеммне сколько сущностей для выполнения задач шаблонизатора?
Это какой-то извращенный подход к архитектуре.
Twig_Autoloader
Twig_Loader_Filesystem
Twig_Loader_String
Twig_Loader_Array
Twig_Environment
И еще черт знает сколько непоятно зачем созданных класов.
И вот это все для инициализации:
Мой идеальный шаблонизатор должен предоставлять весь функционал статическими методами одного класса и не плодить лишней херни.
Ну вот как-то так:
Формат шаблонов должен быть .htm, потому что в первую очередь верстальщику нужна подсветка html синтаксиса в любых условиях, остальное менее важно.
Это какой-то извращенный подход к архитектуре.
Twig_Autoloader
Twig_Loader_Filesystem
Twig_Loader_String
Twig_Loader_Array
Twig_Environment
И еще черт знает сколько непоятно зачем созданных класов.
И вот это все для инициализации:
require_once '/path/to/lib/Twig/Autoloader.php';
Twig_Autoloader::register();
$loader = new Twig_Loader_Filesystem('/path/to/templates');
$twig = new Twig_Environment($loader, array(
'cache' => '/path/to/compilation_cache',
));
Мой идеальный шаблонизатор должен предоставлять весь функционал статическими методами одного класса и не плодить лишней херни.
Ну вот как-то так:
Tpl::$conf=array(
'cache'=>true,
'cache_dir'=>'/cache/tpl/',
'tpl_dir'=>'/templates/'.$theme,
'comment_open_tag'=>'{*',
'comment_close_tag'=>'*}',
/*и так далее, но в общем шаблонизатор должен работать и без каких-либо доп. опций*/
);
Tpl::assign($var);
return Tpl::fetch('news/news.htm');
Формат шаблонов должен быть .htm, потому что в первую очередь верстальщику нужна подсветка html синтаксиса в любых условиях, остальное менее важно.
Вижу что со мной не согласны, пожалуйста, прокомментируйте вашу точку зрения (меня просто очень эта тема волнует, я всегда стремлюсь к тому чтобы код был максимально простым и понятным)
Ну а что вам ответить?!
В большенстве проектом приходится решать сложные задачи, которые не покрываются возможностями шаблонизатора. В Смарти для этого нужно тупо лезть в код и дописывать (и никакого ООП). Тут же все можно изменить через наследование, компоненты разнесены по задачам. Посмотрите остальные библиотеки из проекта компонентов Симфонии, там принцип такой же. Для этого и вводили в PHP ООП. Если вам этого не понятно, то я даже не знаю.
Также никто вам не мешает написать маленький класс со стат методами, который будет оберткой для Twig.
В большенстве проектом приходится решать сложные задачи, которые не покрываются возможностями шаблонизатора. В Смарти для этого нужно тупо лезть в код и дописывать (и никакого ООП). Тут же все можно изменить через наследование, компоненты разнесены по задачам. Посмотрите остальные библиотеки из проекта компонентов Симфонии, там принцип такой же. Для этого и вводили в PHP ООП. Если вам этого не понятно, то я даже не знаю.
Также никто вам не мешает написать маленький класс со стат методами, который будет оберткой для Twig.
Не всегда «собрано в одном файле/классе» == «просто и понятно».
Имхо, в большинстве случаев как-раз наоборот — видишь название класса и понимаешь за что он отвечает. И, зная это, не нужно тратить врремя на изучение всех 3х мегабайтов цельного класса/файла для того чтобы подсмотреть один единственный метод
Имхо, в большинстве случаев как-раз наоборот — видишь название класса и понимаешь за что он отвечает. И, зная это, не нужно тратить врремя на изучение всех 3х мегабайтов цельного класса/файла для того чтобы подсмотреть один единственный метод
UFO just landed and posted this here
Мне, кажется, автор не учитывает, что все шаблонизаторы изначально не создавались монстрами, а тоже были аккуратными, маленькими и быстрыми. Но по мере наращивания функциональности, они всё разрастались и разрастались, памяти ели всё больше, работали всё медленнее.
Боюсь, что через несколько лет развития Twig, когда он догонит по функциональность Smarty, он станет и таким же медленным как Smarty.
И второе, о целесообразности шаблонизаторов в целом. Я тоже когда-то подрабатывал верстальщиком. Так вот я не знаю ни одного верстальщика, который знает какой-либо синтаксис шаблонов, если он конечно не программист (можете сами проверить на фрилансе сколько верстальщиков знают Smarty). Даже XSLT мало кто знает. Так что вёрстку в шаблоны всё равно приходится переделывать программисту. И какой смысл тогда делать промежуточную надстройку? Мы только заставляем программиста учить ещё один язык, который ещё ограничивает его.
Так что я за чистый PHP (или близкий к чистому) в шаблонах!
Боюсь, что через несколько лет развития Twig, когда он догонит по функциональность Smarty, он станет и таким же медленным как Smarty.
И второе, о целесообразности шаблонизаторов в целом. Я тоже когда-то подрабатывал верстальщиком. Так вот я не знаю ни одного верстальщика, который знает какой-либо синтаксис шаблонов, если он конечно не программист (можете сами проверить на фрилансе сколько верстальщиков знают Smarty). Даже XSLT мало кто знает. Так что вёрстку в шаблоны всё равно приходится переделывать программисту. И какой смысл тогда делать промежуточную надстройку? Мы только заставляем программиста учить ещё один язык, который ещё ограничивает его.
Так что я за чистый PHP (или близкий к чистому) в шаблонах!
1. экранирование должен определять не программист и не верстальщик, а _формат выходящего документа_. для примера посмотрите как сделано в xslt — куда бы я не вывел значение переменной она будет правильно заэкранирована. отсюда вывод: шаблонизатор должен на выходе получать не строку, а модель документа, которая уже может быть сериализована в строку.
2. функция преобразования пхп-шных структур в хмл — занимает 20 строчек. тоже мне проблема великого масштаба…
3. применение xslt web-safe-subset позволяет выносить применение xslt на клиента, что позволяет не думать о скорости шаблонизации вообще (для тех, кто в танке — юзерам не надо делать по 100 шаблонизаций в секунду)
4. xslt — это неотключаемая песочница. ибо нефиг.
5. xslt — это громоздкий синтаксис, поэтому лучше сделать свой шаблонизатор, но с компиляцией в xslt, а не php ;-)
2. функция преобразования пхп-шных структур в хмл — занимает 20 строчек. тоже мне проблема великого масштаба…
3. применение xslt web-safe-subset позволяет выносить применение xslt на клиента, что позволяет не думать о скорости шаблонизации вообще (для тех, кто в танке — юзерам не надо делать по 100 шаблонизаций в секунду)
4. xslt — это неотключаемая песочница. ибо нефиг.
5. xslt — это громоздкий синтаксис, поэтому лучше сделать свой шаблонизатор, но с компиляцией в xslt, а не php ;-)
1. Модель документа разве не должна подаваться на вход шаблонизатора? :)
2. У меня она занимала когда-то вообще 4:
Как-то так :) Сейчас бы по другому написал, на чистом PHP, как пишу HTML/xHTML/RSS/e-mail шаблоны сейчас.
3. С ИЕ6 работать будет? (гугл про web-safe-subset ничего не знает, только ваш коммент :)
4. ничего не скажу, не в теме
5. Оригинально :) Заменить 0,1 шаблонизаторов (чистый PHP :) ) на 3 (данные в XML, верстку в XSLT, XML+XSLT в HTML)?
2. У меня она занимала когда-то вообще 4:
requery_once "Smarty.php";
smarty=new Smarty;
smarty->assign('vars', $vars) ;
XML = smarty->fetch('main.tpl');
Как-то так :) Сейчас бы по другому написал, на чистом PHP, как пишу HTML/xHTML/RSS/e-mail шаблоны сейчас.
3. С ИЕ6 работать будет? (гугл про web-safe-subset ничего не знает, только ваш коммент :)
4. ничего не скажу, не в теме
5. Оригинально :) Заменить 0,1 шаблонизаторов (чистый PHP :) ) на 3 (данные в XML, верстку в XSLT, XML+XSLT в HTML)?
1. на вход подаётся модель предметной области (коллекции, объекты, свойства), на выходе — модель документа (элементы, аттрибуты)
2. у меня вообще одну: $this->_core->print_xml( $anyStruct )
3. будет. ие самым первым внедрил поддержку хслт. я его только вчера придумал. ^^' но он довольно просто вычисляется экспериментально…
4. шаблонизатор тут один — по серединке. остальное — трансформеры форматов. [php struct] -/xmlizer/-> [dom document] -/xslt/-> [dom document] -/serializer/-> [string]
2. у меня вообще одну: $this->_core->print_xml( $anyStruct )
3. будет. ие самым первым внедрил поддержку хслт. я его только вчера придумал. ^^' но он довольно просто вычисляется экспериментально…
4. шаблонизатор тут один — по серединке. остальное — трансформеры форматов. [php struct] -/xmlizer/-> [dom document] -/xslt/-> [dom document] -/serializer/-> [string]
1. Можно пример небольшой? Действительно интересно, вроде все слова понятны, а в голове не укладывается: элементы и атрибуты документа — это разве уже не готовый документ?
2. Видимо эта функция 20-30 строк, но вот тоже не врублюсь — конкретную структуру вписать-то можно в 20-30 строк (если она не десятиэтажная), но ведь структуры в реальной жизни разные и в XML они конвертятся по разному, грубо говоря разные DTD. У одной имя свойства — это атрибут будет, у другой значение элемента, у третьей вообще значения не имеет имя свойства, а надо брать тип структуры или имя переменной.
3. Странно, по-моему как раз в ИЕ я не смог ничего вразумительного добиться лет 4-5 назад, еще под PHP4, спасибо, буду знать, что это возможно. надеюсь, что с FF2 и Opera 9 проблем тоже не будет.
4. Чуть-чуть яснее стало, почему я мало понимаю :) я собирал именно текстовый XML, который шел на XSLT-процессор, то есть XML у меня был не форматом, а полноценным представлением предметной области, а XSLT статический на основе HTML верстки, и потом получал с его помощью другое представление.
P.S. Терзают меня смутные сомнения, что когда я пытался пару проектов перевести со Smarty на XML+XSLT, то где-то сделал серьезную ошибку в проектировании. Больше всего похоже на плохой «выбор DTD» в XML — пытался сделать его наиболее полно отражающим предметную область (постоянно сталкиваясь с ограничениями XML типа, что атрибуты должны быть однострочные) и тут же отражающие навигацию сайиа и т.п., не задумываясь как его буду получать из уже существующих PHP-структур, и как конвертить его в HTML
2. Видимо эта функция 20-30 строк, но вот тоже не врублюсь — конкретную структуру вписать-то можно в 20-30 строк (если она не десятиэтажная), но ведь структуры в реальной жизни разные и в XML они конвертятся по разному, грубо говоря разные DTD. У одной имя свойства — это атрибут будет, у другой значение элемента, у третьей вообще значения не имеет имя свойства, а надо брать тип структуры или имя переменной.
3. Странно, по-моему как раз в ИЕ я не смог ничего вразумительного добиться лет 4-5 назад, еще под PHP4, спасибо, буду знать, что это возможно. надеюсь, что с FF2 и Opera 9 проблем тоже не будет.
4. Чуть-чуть яснее стало, почему я мало понимаю :) я собирал именно текстовый XML, который шел на XSLT-процессор, то есть XML у меня был не форматом, а полноценным представлением предметной области, а XSLT статический на основе HTML верстки, и потом получал с его помощью другое представление.
P.S. Терзают меня смутные сомнения, что когда я пытался пару проектов перевести со Smarty на XML+XSLT, то где-то сделал серьезную ошибку в проектировании. Больше всего похоже на плохой «выбор DTD» в XML — пытался сделать его наиболее полно отражающим предметную область (постоянно сталкиваясь с ограничениями XML типа, что атрибуты должны быть однострочные) и тут же отражающие навигацию сайиа и т.п., не задумываясь как его буду получать из уже существующих PHP-структур, и как конвертить его в HTML
1. дом — объектная модель документа — это такая древовидная структура в памяти. вообще, да, для хслт на вход тоже подаётся дом. главное тут то, что при сериализации текст содержащийся в аттрибутах и текст содержащийся в обычных текстовых узлах заэкранируется по разному в соответствии с правилами хмл/хтмл и целевой кодировкой.
2. это всё не нужно… главное — чтобы преобразование было однозначным и без потерь, тогда уже в шаблонах всё замечательно разруливается.
проще на примере показать…
структура: smileg.akmedia.ru/?source:action:get.php
хмлизатор: smileg.akmedia.ru/?source:printer:xmlize.php (криво, но мне хватает)
получаемый хмл: smileg.akmedia.ru/?qwerty
3. там есть нюансы… в ФФ на выходе получается только xhtml-dom а это не очень удобно…
5. я с этим не заморачиваюсь — у меня просто нет аттрибутов во входном документе %-) в хслт с таким документом работать даже проще ;-)
2. это всё не нужно… главное — чтобы преобразование было однозначным и без потерь, тогда уже в шаблонах всё замечательно разруливается.
проще на примере показать…
структура: smileg.akmedia.ru/?source:action:get.php
хмлизатор: smileg.akmedia.ru/?source:printer:xmlize.php (криво, но мне хватает)
получаемый хмл: smileg.akmedia.ru/?qwerty
3. там есть нюансы… в ФФ на выходе получается только xhtml-dom а это не очень удобно…
5. я с этим не заморачиваюсь — у меня просто нет аттрибутов во входном документе %-) в хслт с таким документом работать даже проще ;-)
надеюсь кому-нибудь пригодиться — twig.kron0s.com/
А кто-нибудь уже использовал Twig на больших и нагруженных проектах или слышал об использовании в той или иной компании/проекте?
Можете указать конкретные проекты, нагрузки, размеры команд, сложности, с которыми столкнулись?
Проект начинался на Twig или переходили с чего-то?
Как разработчики справляются с обучением?
Занимаются ли верстальщики написанием/правкой шаблонов или только программеры?
Серьезные ли проблемы дает отсутствие обратной совместимости, например между версиями 0.9.6 и 0.9.9?
Знает ли кто, предполагается ли обратная совместимость в следующих версиях?
Можете указать конкретные проекты, нагрузки, размеры команд, сложности, с которыми столкнулись?
Проект начинался на Twig или переходили с чего-то?
Как разработчики справляются с обучением?
Занимаются ли верстальщики написанием/правкой шаблонов или только программеры?
Серьезные ли проблемы дает отсутствие обратной совместимости, например между версиями 0.9.6 и 0.9.9?
Знает ли кто, предполагается ли обратная совместимость в следующих версиях?
Sign up to leave a comment.
Перевод: Шаблонизаторы в PHP — подведение итогов