Комментарии 312
Пометили б пост как перевод.
Во вторых все рассматриваемые шаблонизаторы мне не понравились. Twig достаточно неплохой вариант но я от него отказался.
Во вторых все рассматриваемые шаблонизаторы мне не понравились. Twig достаточно неплохой вариант но я от него отказался.
Чувствую, скоро здесь будет холивар…
А холивар на оригинале уже закончился и даже итоги подвели. Которые тоже можно будет перевести если кому-нибудь будет интересно.
Итог холивара?
Да, это очень интересно. :)
Да, это очень интересно. :)
НЛО прилетело и опубликовало эту надпись здесь
habrahabr.ru/blogs/php/76021/ повторюсь, ради уведомления на почту
Ну, кто первый начинает?
Поубивал бы за такое:
<?php if ($items): ?>
<?php foreach ($items as $item): ?>
* <?php echo $item ?>
<?php endforeach; ?>
<?php else: ?>
No item has been found.
<?php endif; ?>
согласен. При написании своего компилятора 2 часа убил на собственно компиляцию и еще 4 на «уборку» того что этот компилятор натворил.
Можно конкретнее? За что именно то?
Использование PHP в качестве языка шаблонов имеет право на существование — достаточно читабельно, а также оптимальный вариант по быстродействию.
Как раз такие конструкции намного удобнее применять в шаблонах, чем скобки, и за это разработчикам php большой и жирный плюс.
почему нету PHP Blitz в тестах?
Наверно потому, что он — расширение на C, в отличие от того же Smarty
наверное потому, что тогда цифры были бы другие, а тут вроде как новый шаблонизатор всех победил…
А никто не знает, есть ли Blitz под PHP 5.3?
я думаю что автор сказал бы что в Blitz нет наследования и режима песочницы :))
И СTPP2 нет. Вот незадача, они препятствуют концепции «код в шаблонах» и рвут всех по производительности :)
Зачем в шаблоне фильтровать/экранировать данные? Незачем ответственность за безопасность перекладывать на верстальщика.
Чтобы логика представления была в виде, а не в контроллере. Иначе замена вида может потянуть за собой замену представления в контроллере.
можно отфильтравать данные перед отдачей их шаблону, благо бьекты могут это делать в методах перед выдачей, да и array_map никто не отменял
Почитайте на досуге про MVC что ли.
Представьте. у вас половина переменных — текстовые строки. а другая — HTML- код (выводится без эскейпинга). И что, вы предлагаете в контроллере пропускать часть переменных (руками указывая каких!!) через array_map()? Что за бред?
Представьте. у вас половина переменных — текстовые строки. а другая — HTML- код (выводится без эскейпинга). И что, вы предлагаете в контроллере пропускать часть переменных (руками указывая каких!!) через array_map()? Что за бред?
я могу отфильтровать все в модеи, у меня есть фильтры для этого, которые делают всю грязную работу и возвращают чистые строки, которые спокойно можно использовать в виде
зы: почитайте на досуге про MVC, только почитайте нечто более нужное чем введение из википедии
зы: почитайте на досуге про MVC, только почитайте нечто более нужное чем введение из википедии
Вы в * модели* делаете HTML-эскейпинг??? А если завтра вам надо будет добавить вывод в json или plain text, вы все методы во всех моделях продублируете, да? $model->getAllForHTML(), $model->getAllForJSON() и так далее?
И как тогда, если данные эскейпятся, получить «чистые» данные? Например, для записи в какую-нибудь БД, отправки по какому-нибудь протокол, или еще зачем-нибудь.
И как тогда, если данные эскейпятся, получить «чистые» данные? Например, для записи в какую-нибудь БД, отправки по какому-нибудь протокол, или еще зачем-нибудь.
во-первых есть замечательный паттрен: фабричный метод… дублирования методов не будет, во вторых допустим Вам приходят в шаболн данные, вы что будете ставить кучу ифов чтоб проверить это HTML, и его надо экранировать, либо это JSON и тут надо обработать их без экранирования?
я в любом случае получу чистые данные, при выводе в шаблон этим занимаются фильтры, при записи в бд этим занимаются методы для записи в бд…
зы: эскейпинг — частный случай, я в модели _привожу данные в нужный мне вид_
я в любом случае получу чистые данные, при выводе в шаблон этим занимаются фильтры, при записи в бд этим занимаются методы для записи в бд…
зы: эскейпинг — частный случай, я в модели _привожу данные в нужный мне вид_
Ну я например знаю, что title у меня — plain text, а content — это HTML :) Впрочем, большинство данных берется из БД, а значит является plain text, который надо эскейпить.
Если же вам приходит большой массив данных, например таблица, содержащая колонки и с обычным текстом, и с HTML, то к ней должен прилагаться массив с описанием типов данных в каждой колонке :)
Т.е. модель всегда возвращает нормальные данные, пригодные для любого использования. Ведь то, что мы получим, мы не обязательно выведем в HTML формате, мы можем положить их в другую таблицу, отправить по почие, засунуть в кеш, и т.д.
Форматирование и оформление данных (типа вывод даты в формате «Сегодня, 2 часа назад») должен делаться в Виде, как иначе-то? И зачем плодить для этого какие-то фабрики?
> во вторых допустим Вам приходят в шаболн данные, вы что будете ставить кучу ифов чтоб проверить это HTML, и его надо экранировать, либо это JSON и тут надо обработать их без экранирования?
Для разных форматов вывода (HTML, json и прочее) используются разные шаблоны (а иногда и разные компоненты View).
Если же вам приходит большой массив данных, например таблица, содержащая колонки и с обычным текстом, и с HTML, то к ней должен прилагаться массив с описанием типов данных в каждой колонке :)
Т.е. модель всегда возвращает нормальные данные, пригодные для любого использования. Ведь то, что мы получим, мы не обязательно выведем в HTML формате, мы можем положить их в другую таблицу, отправить по почие, засунуть в кеш, и т.д.
Форматирование и оформление данных (типа вывод даты в формате «Сегодня, 2 часа назад») должен делаться в Виде, как иначе-то? И зачем плодить для этого какие-то фабрики?
> во вторых допустим Вам приходят в шаболн данные, вы что будете ставить кучу ифов чтоб проверить это HTML, и его надо экранировать, либо это JSON и тут надо обработать их без экранирования?
Для разных форматов вывода (HTML, json и прочее) используются разные шаблоны (а иногда и разные компоненты View).
вы записываете в бд не обработанные данные и потом их чистите при выводе? это верх тупости, если я читаю данные из бд, значит они уже обработаны и в них нет ничего лишнего, единственные обрабатываемые варианты — формы, там ковычки могут все испортить, но конкретно в моем случае я использую зенд, и за вывод элеменотв отвечают соответствующие классы
в виде форматирование данных типа «Сегодня, 2 часа назад» элементарно справится набор функций/классов, это к делу не относится (хотя тоже своего рода модели)
для разных форматов и я могу использовать разные шаблоны
может быть я неправильно понял, или вы на самом деле говорите про htmlentities? если да, то мы говорим о разных вещах
в виде форматирование данных типа «Сегодня, 2 часа назад» элементарно справится набор функций/классов, это к делу не относится (хотя тоже своего рода модели)
для разных форматов и я могу использовать разные шаблоны
может быть я неправильно понял, или вы на самом деле говорите про htmlentities? если да, то мы говорим о разных вещах
> вы записываете в бд не обработанные данные
Я записываю данные в БД, кеш и т.д. в их исходном виде, как есть, и та же кавычка там хранится как кавычка (") а не & quot; Что вы имеете в виду под «если я читаю данные из бд, значит они уже обработаны», я не понял.
Естественно, в модели при записи данных в БД могут проверяться разные условия, например тип данных, длина, допустимые символы и т.д.
Про форматирование данных в шаблоне — я имею в виду, что и htmlentities, и date_format/number_format делаются там.
Я записываю данные в БД, кеш и т.д. в их исходном виде, как есть, и та же кавычка там хранится как кавычка (") а не & quot; Что вы имеете в виду под «если я читаю данные из бд, значит они уже обработаны», я не понял.
Естественно, в модели при записи данных в БД могут проверяться разные условия, например тип данных, длина, допустимые символы и т.д.
Про форматирование данных в шаблоне — я имею в виду, что и htmlentities, и date_format/number_format делаются там.
Правильно товарищ говорит. View должен сам квотить данные, которые в него приходят, автоматически. Иначе получается опасность XSS.
меня бесят строки типа {$item|htmentities|dateformat:"%m/%d"|default" "} это ведь все поидее экранирование? я имею ввиду что проще сделать модельку для вьюв
<?php Date::format( $item, Date::SHORT ) ?>
<?php Date::format( $item, Date::SHORT ) ?>
Fabien как раз и говорит о том что оно должно быть включено по-умолчанию. Имея возможность местами выключать.
уже делали такую штуку, называется magic_quotes в итоге строки получались на подобии «qwe\\\»asd" потому как программа не всегда знает когда это нужно а когда нет, программист лучше знает места где это надо и реализовать в «хелпере/функции/методе/модели» лишний раз htmlentities не составит большого труда
да, строчка подкачала, я имел ввиду такое: «qwe\\\«asd»
Эскейпить по-умолчанию, выключая в ненужных местах. Мне такой вариант больше нравится, как и автору.
может я не прав, но включение и отключение экранизации при изменении шаблода другой программист может не заметить, а явную экраницацию трудно пропустить, может некоторым это покажется мелочью, но когда таких мелочей больше, это начинает сбивать с толку и приводить к глупым ошибкам
НЛО прилетело и опубликовало эту надпись здесь
лень конечно, но вдруг мне _нужно_ будет что-то сделать с данными в модели и там я их экранирую, не получится кака?
НЛО прилетело и опубликовало эту надпись здесь
Вы очень хороший пример привели, с magic_quotes, но, кажется, не в том смысле, который в него вкладывали. Это как раз пример о том, что не надо делать экранирование в модели, потому что модель не знает, где будут выводиться данные и в каком формате. Ну а к автоквотингу в шаблоне пример с magic_quotes имеет малое отношения.
Не уверен, что правильно это реализовывать в модели, скорее просто хелпер, который относится все-таки к отображению.
какая разница как называть модель? модель, хелпер, фильтр — это все отдельно взятая еденица кода которая реализует логику, дабы не загромождать контроллер и вид… по сути это и есть фильрация данных, и про нее я и говорил, мы просто с egorinsk неправильно поняи друг друга
Ну назвать-то можно как угодно, главное сознавать, что форматирование данных это функция вида, а не контроллера или модели ;)
да, это функция вида, однако ниже человек говорил что вид != шаблон, и я его поддерживаю, в шаблоне должно быть как можно меньше логики. надо строить архитекруту так, чтоб шаблоны могли обрабатываться банальным str_replace, если это так, тогда архитекрута идеальна, ну это мое мнение :)
Ну да, шаблон часть вида :) Но вот слабо представляю, как через str_replace сделать вывод таблицы неизвестных размеров, так чтобы весь HTML код был в одном файле :-/
// controller
$this->view->userList = $objModel->getUserList();
//model
// бла бла, бд итд
foreach($users as $id => $user)
{
$objRow->add($user['nickName']);
$objRow->add($user['email']);
…
$objRow->addAction(Models_Row::EDIT, $id);
$objRow->addAction(Models_Row::DELETE, $id);
$objTable->addRow($objRow);
}
return $objTable->render();
// template
{$userList}
как-то так
$this->view->userList = $objModel->getUserList();
//model
// бла бла, бд итд
foreach($users as $id => $user)
{
$objRow->add($user['nickName']);
$objRow->add($user['email']);
…
$objRow->addAction(Models_Row::EDIT, $id);
$objRow->addAction(Models_Row::DELETE, $id);
$objTable->addRow($objRow);
}
return $objTable->render();
// template
{$userList}
как-то так
в данном случае на вид ложится обязанность структурировать шаблоны, следить за вложенностями в зависимости от контроллера, а вся логика ложится на модели
я не говорю что так нужно делать, я говорю что так _можно_ делать, и ничего плохого в этом нет, дизайнер не заморачивается в логике, он пишет только классы цсс, которые влияют на внешний вид
я не говорю что так нужно делать, я говорю что так _можно_ делать, и ничего плохого в этом нет, дизайнер не заморачивается в логике, он пишет только классы цсс, которые влияют на внешний вид
если кто-то слишком строго относится к моделям, можно вместо модели использовать хелпер вида, это не важно, всеравно логика не изменится
Разница есть, модель — компонент для работы с данными предметной области (дата — это не часть предметной области), в первую очередь, а хелпер — это вспомогательный компонент View. Переименовывать их не стоит, так как возникает непонимание ))
> это ведь все поидее экранирование?
Экранирование — это htmlspaecialchars(), остальное — это форматирование :)
В вашем примере — можно конечно сделать хелпер date_format_for_html, но по-моему, проще переименовать хелпер htmlspaecialchars() в «e» и тогда все будет проще: {$item.title|e}, {$item.date|date:"%d.%m"|e} (хотя дату эскейпить необязательно). По моему, так это лучше, чем лишние скобки и знаки вопроса.
А с автоквотингом — даже |e писать не надо, просто {$item.title} :)
Экранирование — это htmlspaecialchars(), остальное — это форматирование :)
В вашем примере — можно конечно сделать хелпер date_format_for_html, но по-моему, проще переименовать хелпер htmlspaecialchars() в «e» и тогда все будет проще: {$item.title|e}, {$item.date|date:"%d.%m"|e} (хотя дату эскейпить необязательно). По моему, так это лучше, чем лишние скобки и знаки вопроса.
А с автоквотингом — даже |e писать не надо, просто {$item.title} :)
если дело только в скобках то это глупо, надо смотреть с точки зрения вида а не с точки зрения написания 4-х лишних символов
Так пайп выглядит очень даже хорошо :) Сразу видно, что берется переменная, пропускается через один фильтр, потом другой, а представьте вызов например 4 функций друг за другом.
И мне не нравятся лишние символы, {$title|default:""|e} (по моему субъективному мнению) в разы лучше [php htmlspecialchars($title? $title: '', ENT_QUOTES, 'utf-8'); ]
И мне не нравятся лишние символы, {$title|default:""|e} (по моему субъективному мнению) в разы лучше [php htmlspecialchars($title? $title: '', ENT_QUOTES, 'utf-8'); ]
Да, Вы правы, в примерах которые Вы показали, действительно шаблонные методы смотрятся аккуратней, вы не учли что так не делают, пишут хелперы/функции, ведь никто не мешает сделать так:
<?php Filter::escape( $title ) ?> все понятно и красиво, меня не напрягает написать 5 лишних символов, всегда можно макрос написать и поставить горячие клавиши, а еще я могу сделать так:
<?php Customize::description( $desc ) ?> и у меня появится ровно ХХ символов описания со ссылочкой «далее...», причем меня не будет волновать utf8 это или нет, нужно ли экранировать, ставить 3 точки или нет, все внутри, и даже больше, все в конфиге… такое можно сделать и в шаблонизаторе, безусловно, но если в итоге будет тоже самое но на 5 символов меньше, то я не вижу разницы
<?php Filter::escape( $title ) ?> все понятно и красиво, меня не напрягает написать 5 лишних символов, всегда можно макрос написать и поставить горячие клавиши, а еще я могу сделать так:
<?php Customize::description( $desc ) ?> и у меня появится ровно ХХ символов описания со ссылочкой «далее...», причем меня не будет волновать utf8 это или нет, нужно ли экранировать, ставить 3 точки или нет, все внутри, и даже больше, все в конфиге… такое можно сделать и в шаблонизаторе, безусловно, но если в итоге будет тоже самое но на 5 символов меньше, то я не вижу разницы
А меня — напрягает. Понятно, что есть сокращения в редакторе, и т.д., но тут именно выглядит код по-разному. На php я пишу контроллеры и модели. а вот шаблоны — на отдельном языке :)
Плюс есть подвох в ваших «составных фильтрах». что завтра вам понадобится такой же, но без эскейпа, или еще что-нибудь там надо поменять будет — тогда ваш подход даст трещину ))
И мне почему-то интуитивно не нравится эта визуальная каша из тегов и скобок [?php, ну некрасиво по-моему.
Хотя я видел шаблонизатор (serpent), который просто заменял [?php и [?php echo на скобки, а сам код оставался на php.
В любом случае. в php нет наследования шаблонов, так что мне не подходит.
Хотя, наверно это — дело вкуса, если у вас нормаьно получается на php — пишите на php.
Плюс есть подвох в ваших «составных фильтрах». что завтра вам понадобится такой же, но без эскейпа, или еще что-нибудь там надо поменять будет — тогда ваш подход даст трещину ))
И мне почему-то интуитивно не нравится эта визуальная каша из тегов и скобок [?php, ну некрасиво по-моему.
Хотя я видел шаблонизатор (serpent), который просто заменял [?php и [?php echo на скобки, а сам код оставался на php.
В любом случае. в php нет наследования шаблонов, так что мне не подходит.
Хотя, наверно это — дело вкуса, если у вас нормаьно получается на php — пишите на php.
>что завтра вам понадобится такой же, но без эскейпа, или еще что-нибудь там надо поменять будет — тогда ваш подход даст трещину
если вам надо чтоб модель возвращала разные данные, вы делаете либо еще один метод, либо еще один парамерт, так же можно сделать в фильтрах
я пишу на смарти =) я не говорил что шаблонизаторы — плохо, я говорил что пхп — не плохо
если вам надо чтоб модель возвращала разные данные, вы делаете либо еще один метод, либо еще один парамерт, так же можно сделать в фильтрах
я пишу на смарти =) я не говорил что шаблонизаторы — плохо, я говорил что пхп — не плохо
а еще вот сюда взгляните, очень хороший пример обработки данных перед отдачей их в шаблон, там вообще в шаблоне не надо логики
habrahabr.ru/blogs/php/75901/#comment_2208033
habrahabr.ru/blogs/php/75901/#comment_2208033
вы кстати никогда не думали что вид тоже может использовать модели, только для своих целей (опять же «Сегодня, 2 часа назад»)
Если бы вы меньше полагались на книжки про MVC и старались сделать реальное разделение логики от данных, то не делали бы таких категоричных выводов. Правильно, если вы всю логику представления реализуете в шаблоне, то в нем и фильтром и всем остальным будете заниматься, следуя такому подходу, вы потом захотите больше алгоритмических возможностей в шаблоне, от чего появляются мега шаблонизаторы, точно также пхп развивался.
Ну я не только полагаюсь на книжки, я свои велосипеды пишу, и голову не раз уже ломал в поисках решений для разных частей этого велосипеда, чтобы например удобство разработки сочеталось с нормальной производительностью.
В View — логика вывода данных, которые он получает от Контроллера (ну или Модели, если используется такая схема), соответсвенно все форматирования и эскейпы стоит делать именно здесь. Если вам *принципиально*, чтобы не использовался код в шаблоне — разбиваете View на код и на шаблоны. В Controller — логика обработки запросов пользователя, вызов всех остальных компонентов, нужных для вывода страницы, что тут сложного?
Ну а Model содержит логику хранения, получения, обновления данных предметной области.
> следуя такому подходу, вы потом захотите больше алгоритмических возможностей в шаблоне, от чего появляются мега шаблонизаторы, точно также пхп развивался.
Мега шаблонизаторы (типа монстра смарти) появляются из-за попыток сделать универсальное решение на все случаи жизни с возможностью замены чего угодно на что угодно, а не от этого.
В View — логика вывода данных, которые он получает от Контроллера (ну или Модели, если используется такая схема), соответсвенно все форматирования и эскейпы стоит делать именно здесь. Если вам *принципиально*, чтобы не использовался код в шаблоне — разбиваете View на код и на шаблоны. В Controller — логика обработки запросов пользователя, вызов всех остальных компонентов, нужных для вывода страницы, что тут сложного?
Ну а Model содержит логику хранения, получения, обновления данных предметной области.
> следуя такому подходу, вы потом захотите больше алгоритмических возможностей в шаблоне, от чего появляются мега шаблонизаторы, точно также пхп развивался.
Мега шаблонизаторы (типа монстра смарти) появляются из-за попыток сделать универсальное решение на все случаи жизни с возможностью замены чего угодно на что угодно, а не от этого.
Почему тогда такая категоричность с фильтром данных именно в шаблоне, если сами знаете, как надо бы делать (в коде View)?
Представление — это отдельный компонент системы со своей логикой предназначенной для подготовки данных для рендеринга в соответствующий формат, обычно в html. Шаблон — это как скин у десктопных программ — ему не нужна логика. Почему вы считаете шаблон видом? Если в шаблон запихивать логику, то рано или поздно рождаются монстры типа смарти со своим фактически языком программирования. А у нас какая цель — чтобы шаблон просто отобразил то, что ему дали.
На сегодняшний день ещё нет идеально реализованного «вида», а ведь поверьте, через детализацию шаблонов в них даже циклы и условные операторы не нужны будут.
На сегодняшний день ещё нет идеально реализованного «вида», а ведь поверьте, через детализацию шаблонов в них даже циклы и условные операторы не нужны будут.
Поэтому разница между <?=$v['head']?> и %v[head]% в паре символов и в скорости. Лучше выбрать скорость, так визуальная разница ничтожна.
Использование коротких тегов для PHP не самый лучший вариант.
Отсюда первый вариант будет выглядеть так:
<?php echo $v['head'] ?>
Уже не так компактно, как хотелось бы.
Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
На мой личный взгляд — слишком поперенавороченно получается. =)
В любом упрощении, главное — не усложнить.
Отсюда первый вариант будет выглядеть так:
<?php echo $v['head'] ?>
Уже не так компактно, как хотелось бы.
Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
На мой личный взгляд — слишком поперенавороченно получается. =)
В любом упрощении, главное — не усложнить.
Если удастся вытащить полностью логику из шаблона, то конечно лучше применить простые вставки, типа %v[head]%, тогда мы ещё и предотвратим использование php. Когда не получается обойтись без логики в шаблоне, тогда лучше не извращаться и применять php. :)
> Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
Поэтому я говорю о детализации. Шаблоны могут быть вплоть до минимальных единиц информации в системе, в моём случае – это сущности. В реальности может получиться, что не потребуется создавать шаблон для новости, так как новость соберется из шаблонов её заголовка и текста. Избавится от необходимости логики в шаблоне реально, и при этом иметь супер гибкость. Всё зависит от архитектуры системы и вопрос этот не прост для обсуждения здесь. Конечно, компонент представления получится не легким, но это как с детализацией трехмерной графики – отличная картинка за большее процессорное время. Во всяком случаи мы не анимацию делаем, и может использовать многоуровневое кэширование.
> Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
Поэтому я говорю о детализации. Шаблоны могут быть вплоть до минимальных единиц информации в системе, в моём случае – это сущности. В реальности может получиться, что не потребуется создавать шаблон для новости, так как новость соберется из шаблонов её заголовка и текста. Избавится от необходимости логики в шаблоне реально, и при этом иметь супер гибкость. Всё зависит от архитектуры системы и вопрос этот не прост для обсуждения здесь. Конечно, компонент представления получится не легким, но это как с детализацией трехмерной графики – отличная картинка за большее процессорное время. Во всяком случаи мы не анимацию делаем, и может использовать многоуровневое кэширование.
Шаблон это не трафарет, и в нем должна присутствовать логика вывода. Гораздо проще и удобнее в шаблон передать объект и уже там определять, какие свойства выводить. Иначе придется править в 2х местах: сначала определять — что передавать в шаблон, а потом как это выводить.
Оно это так, мне тоже так удобней, но это приводит к нарастанию логики внутри шаблона, от чего многие хотят избавится, и думают, что создав отдельный слой — шаблонизатор, всё будет гуд, но это утопия. Если нужно избавится от логики в шаблоне, то нужно работать над архитектурой системы, над архитектурой компонента представления. Решением я вижу только в детализации шаблонов. Если же архитектура требует логики в шаблоне, то люди, не извращайтесь, используйте пхп :))
Кстати, чтоб передать шаблону объект, его ведь тоже надо подготовить, а кроме объекта может понадобится служебная информация, либо информация об объекте относительно других объектов, например порядковый номер, именование (чем этот объект является для кого-то). И поэтому образуется отдельно логика, отдельно шаблон, либо размазанная логика как в шаблоне так и в других местах системы, что не упрощает шаблонизацию.
>Шаблон — это как скин у десктопных программ — ему не нужна логика
Логика вывода нужна обязательно. Например, выделить важную новость в списке жирным. И полного разделения на контроллер и вид тут не получить в принципе. И придётся или HTML-код, часть представления, засовывать в контроллер, или условный оператор выносить в шаблон. Я сторонник второго подхода, так как он идеологически намного чище. Видом должен заниматься вид. Даже если это требует программирования в шаблоне.
>На сегодняшний день ещё нет идеально реализованного «вида»
И не может быть. На то он и идеальный, чтобы быть нереализуемым в реальном мире на реальных задачах.
Логика вывода нужна обязательно. Например, выделить важную новость в списке жирным. И полного разделения на контроллер и вид тут не получить в принципе. И придётся или HTML-код, часть представления, засовывать в контроллер, или условный оператор выносить в шаблон. Я сторонник второго подхода, так как он идеологически намного чище. Видом должен заниматься вид. Даже если это требует программирования в шаблоне.
>На сегодняшний день ещё нет идеально реализованного «вида»
И не может быть. На то он и идеальный, чтобы быть нереализуемым в реальном мире на реальных задачах.
> Например, выделить важную новость в списке жирным.
Во! Полезная зацепка. Шаблон должен выбираться не только по типу объекта и, например, места — текущего адреса, а вообще по состоянию объекта, в зависимости, какие у него свойства, какое отношение с другими объектами. Это может натолкнуть на реализацию продвинутой модели данных. Эта очень интересная тема))
Во! Полезная зацепка. Шаблон должен выбираться не только по типу объекта и, например, места — текущего адреса, а вообще по состоянию объекта, в зависимости, какие у него свойства, какое отношение с другими объектами. Это может натолкнуть на реализацию продвинутой модели данных. Эта очень интересная тема))
1. Слишком громоздко будет и неудобно. И чем больше таких параметров, тем сложнее.
2. Опять же, часть работы верстальщика переедет на программиста. Вот потребуется верстальщику ввести изменение по какому-то критерию, а в коде этого не предусмотрено. Вместо того, чтобы написать простенькое условие, придётся модифицировать код или схему.
2. Опять же, часть работы верстальщика переедет на программиста. Вот потребуется верстальщику ввести изменение по какому-то критерию, а в коде этого не предусмотрено. Вместо того, чтобы написать простенькое условие, придётся модифицировать код или схему.
Спорить не буду, возможно, громоздко, но ещё не проверено. По второму пункту вы просто чуток не поняли, не нужно будет писать каждый раз логику для выбора шаблона – это будет единый алгоритм выбора шаблона в соответствии с состоянием объекта, который шаблонизируем. Вопрос пока чисто теоретический, на практике ещё не понятно как провести это соответствие, ведь шаблон – это просто файл, в него либо логику пиши, либо где-то храни конфигурацию, при каком состоянии объекта использовать именно этот шаблон. От этого и возникает мысль о громоздкости, согласен. Но, думаю, довольно гибко и просто было бы — чтоб сделать отображение топиков, у которых ещё нет комментариев — достаточно создать шаблон, который будет автоматически применяться для таких топиков.
>Логика вывода нужна обязательно. Например, выделить важную новость в списке жирным.
взгляните на Zend_Form из зендовского фреймверка, это отличный пример «представления», в шаблоне обходится все без логики, только вывод формы, причем возможности вплоть до красной звездочки возле обязательного поля
взгляните на Zend_Form из зендовского фреймверка, это отличный пример «представления», в шаблоне обходится все без логики, только вывод формы, причем возможности вплоть до красной звездочки возле обязательного поля
Ох, а я вот не люблю ZF за излишнюю универсальность и разбиение на слишком крошечные компоненты. Что касается форм — в Zend отвратительно сделаны декораторы. Так как приходится в классе формы, рядом с типами полей и валидаторами писать HTML код. Это в общем плохо, так как HTML-код должен быть в шаблоне.
А так как я увлекаюсь велосипедостроением, то для себя придумал (но пока не реализовал) другое решение проблемы декорирования форм, оно выглядит примерно так:
{form data=$form}
{block 'label-for-username'}[strong]{parent}[/strong]{/block}
{block 'form-element-password'}{parent}[p class='hint']Пожалуйста, не используйте слабые пароли! [/p]{/block}
{/form}
Надеюсь код понятен, первый тег {block} декорирует label, заключая его текст в тег strong, второй добавляет абзац текста после поля «password».
А так как я увлекаюсь велосипедостроением, то для себя придумал (но пока не реализовал) другое решение проблемы декорирования форм, оно выглядит примерно так:
{form data=$form}
{block 'label-for-username'}[strong]{parent}[/strong]{/block}
{block 'form-element-password'}{parent}[p class='hint']Пожалуйста, не используйте слабые пароли! [/p]{/block}
{/form}
Надеюсь код понятен, первый тег {block} декорирует label, заключая его текст в тег strong, второй добавляет абзац текста после поля «password».
Наследование в шаблонах!? Вы шутите? Верстальщик не программист, он не должен знать таких вещей как наследование, а в идеальном случае и цикл, переменная и т.п.
Верстальщики прекрасно знают что такое парадигма наследования, хотя бы из css. И не пользоваться этой мощью в шаблонах — путь в говнокод.
Я предлагаю их избавить от необходимости знать что это. Граница вхождения опуститься. А говнокод будут писать всегда, какие бы средства не предоставлять. Я просто всегда пропагандирую принцип KISS
Что говнокод пишется с помощью любых средств — это несомненно. Только способствовать этому, не применяя общеизвестные практики (прикрываясь их типа сложностью), уменьшающие вероятность говнокода, это темный путь силы. Да и нет ничего сложного в наследовании, это способен понять любой верстальщик.
Количество говонокода можно уменьшить лишь прокачав мозги и только.
Вам нравиться наследование — используйте. Если ваша команда состоит из верстальщиков-программистов, то несомненно вы получите выгоду от наследования.
С моей стороны понимайте это заботой о пользователе. Чем меньше он знает о программистских штуках тем лучше для него. И если был бы простой способ избавить шаблоны от циклов и переменных — я бы сделал это.
Вам нравиться наследование — используйте. Если ваша команда состоит из верстальщиков-программистов, то несомненно вы получите выгоду от наследования.
С моей стороны понимайте это заботой о пользователе. Чем меньше он знает о программистских штуках тем лучше для него. И если был бы простой способ избавить шаблоны от циклов и переменных — я бы сделал это.
Такое чувство, что верстальщиков стараются оградить совершенно от каких-либо действий и новых знаний… Вы боитесь что работы не хватит что ли? Почему верстальщику не знать синтаксисы простейшие? Это бред полный, как по мне… Тогда зачем у программистов такая масса новых «игрушек»: всякие библиотеки новые, новые движки, новые версии софта? А что у верстальщиков? Один и тот же код — день за днем, сайт- за сайтом, через полгода активной работы, сделается 75-85% всех вариантов возможных, дальше все шаблонно… И что тогда? Как эти бедолаги крышей не сворачиваются?..
PS: мое личное мнение, что пора подталкивать верстальщиков к работе более прогрессивной… и чтобы на некоторых участках они могли заменять и программиста, для того, чтобы у более «производительного» коллеги развязаны были руки на другие вопросы. Один из вариантов лучших только — это верстальщик с знанием JS и какого-либо JS framework'a, но для таких освоить, синтаксис того-же Smarty — это час на чтение, или день на метод научного тыка.
PS: мое личное мнение, что пора подталкивать верстальщиков к работе более прогрессивной… и чтобы на некоторых участках они могли заменять и программиста, для того, чтобы у более «производительного» коллеги развязаны были руки на другие вопросы. Один из вариантов лучших только — это верстальщик с знанием JS и какого-либо JS framework'a, но для таких освоить, синтаксис того-же Smarty — это час на чтение, или день на метод научного тыка.
Поймите, менять шаблон может не только профессиональный верстальщик, но и студент, установивший свой первый сайт или начальник какой нибудь фирмы, чтобы не тревожить программистов. Что плохого в желании помочь таким людям?
А чем от человека меньше требуется, тем ему можно меньше платить, вот и выгода.
А чем от человека меньше требуется, тем ему можно меньше платить, вот и выгода.
Я еще не видел ни одного верстальщика, кто бы занимался натягиванием шаблона на систему. Все это всегда делают программисты — верстальщик только передает им готовые шаблоны.
Потому что, чтобы верстальщику заполнить шаблон переменными, ему нужно знать эти переменные, нужно лезть в контроллер, знать, какие хелперы используются в шаблонах и прочее. Покажите мне хоть одного верстальщика, кто будет этим заниматься, даже если он будет знать досконально систему, под которую он верстает. Это не его круг задач, все что от него требуется — тупо сверстать и иногда, написать js.
Потому что, чтобы верстальщику заполнить шаблон переменными, ему нужно знать эти переменные, нужно лезть в контроллер, знать, какие хелперы используются в шаблонах и прочее. Покажите мне хоть одного верстальщика, кто будет этим заниматься, даже если он будет знать досконально систему, под которую он верстает. Это не его круг задач, все что от него требуется — тупо сверстать и иногда, написать js.
Ситуация примерно схожая с яваскриптами и аяксом. Мы поступаем следующим образом — пишем что и по какому адресу взять/положить (согласовываем api) и все счастливы
А верстальщик который натягивает шаблоны на приложение, по-логике, должен существовать. Почему это программисты должны думать о том что и где отобразить.
barba.habrahabr.ru/ с удовольствием правит шаблоны symfony :) Я думаю что стоит обучать верстальщиков работе с шаблонами, освобождая программистов у которых итак хватает заморочек
А верстальщик который натягивает шаблоны на приложение, по-логике, должен существовать. Почему это программисты должны думать о том что и где отобразить.
barba.habrahabr.ru/ с удовольствием правит шаблоны symfony :) Я думаю что стоит обучать верстальщиков работе с шаблонами, освобождая программистов у которых итак хватает заморочек
Верстальщики прекрасно знают что такое парадигма наследования, хотя бы из css. И не пользоваться этой мощью в шаблонах — путь в говнокод.
Проблема в том, что за словом «наследование» скрывается куча разных по смыслу понятий. В программировании, наследованием называют логическое отношение обобщения (is-A) для типов данных. В css же, под наследованием понимается механизм каскадной композиции свойств.
Да ну. Возможно наследование и так. Но вы предлагаете все генерировать программисту в контроллере, а верстальщику только указывать места вывода переменных? А если нужно сменить хоть один символ, просить программиста?
Значит нужно искать в проект умного верстальщика, который знает что такое наследование и цикл, и переменная )))
Значит нужно искать в проект умного верстальщика, который знает что такое наследование и цикл, и переменная )))
Прекрасно. Вы предлагает изменять верстальщику логику работы программы по своему усмотрению.
А потом программист часами дебажит код в поисках чего же там чертподери не так.
А потом программист часами дебажит код в поисках чего же там чертподери не так.
Нет, я просто говорю о том, что верстальщик — это не только человек который знает хтмл. Ведь внешний вид сайта — это и количество новостей в блоке, и то как такой каждый блок выглядит, разные стили дял четных и нечетных строк таблицы(знаю что такое можно и на js сделать, и на css, но в случае css не полная поддержка браузеров) — все это циклы и условия в шаблонах. Если за каждой такой проблемой верстальщик будет бегать с к программисту, хорошего с этого точно не получится. Будет проще нанять программиста-верстальщика, который сам все сделает.
Насчет поисков и дебага — нужно правильный шаблонизатор использовать, который не даст верстальщику писать чистый php.
Да и ничего страшного, если верстальщик выучит пару новых команд, html и css как то же выучил?
Насчет поисков и дебага — нужно правильный шаблонизатор использовать, который не даст верстальщику писать чистый php.
Да и ничего страшного, если верстальщик выучит пару новых команд, html и css как то же выучил?
Не все верстальщики незнакомы с программированием. Не все программисты не являются верстальщиками.
Наш верстальщик с удовольствием пользуется view.yml (symfony) и регулярно спрашивает как реализовать что-нибудь в шаблоне. Так что может стоит разделять на несолько категорий:
* нарезальщик мактов
* верстальщик + клиентское программирование
* и, например, веб-технолог или веб-дизайнер (насколько я понимаю, в русском языке под этим словом понимают нечто отличное от оригинального web-designer) — тот который занимается не только непосредственно версткой, но и, по возможности, ее внедрением в приложение.
* нарезальщик мактов
* верстальщик + клиентское программирование
* и, например, веб-технолог или веб-дизайнер (насколько я понимаю, в русском языке под этим словом понимают нечто отличное от оригинального web-designer) — тот который занимается не только непосредственно версткой, но и, по возможности, ее внедрением в приложение.
Да вы упоротый, расскажите мне тогда, как можно сделать шаблоны для сайта без наследования и *без* копипаста кода (что является крайне дурной практикой), ну?
Вариант «использовать include header/sidebar/footer» — уродский, негибкий и создает кучу сложностей.
Наученный горьким опытом, я больше не использую шаблонизаторов без поддержки наследования. Сами жрите свои кактусы, если нравится.
> Верстальщик не программист, он не должен знать таких вещей как наследование, а в идеальном случае и цикл, переменная и т.п
Ну значит, тогда верстальщик будет делать статические ХТМЛ-страницы, а программист — вписывать туда циклы и наследование.
Вариант «использовать include header/sidebar/footer» — уродский, негибкий и создает кучу сложностей.
Наученный горьким опытом, я больше не использую шаблонизаторов без поддержки наследования. Сами жрите свои кактусы, если нравится.
> Верстальщик не программист, он не должен знать таких вещей как наследование, а в идеальном случае и цикл, переменная и т.п
Ну значит, тогда верстальщик будет делать статические ХТМЛ-страницы, а программист — вписывать туда циклы и наследование.
Сперва, ну стоит другие варианты называть уродскими, если они лично вам не нравятся.
Вариант с include более понятный, существует еще со времен SSI. Нужно заменить title в заголовке — сделайте его переменной.
Вариант с include более понятный, существует еще со времен SSI. Нужно заменить title в заголовке — сделайте его переменной.
НЛО прилетело и опубликовало эту надпись здесь
> Нужно заменить title в заголовке — сделайте его переменной.
Почему это плохо? Потому что, задать название страницы я могу, только явно указав переменную title в контроллере, а в шаблоне я название задать не могу. Вариант типа [?php $title ='lalaa'; include 'header' ?] я даже не рассматриваю из-за неуклюжести (так как это имитация вызова функции с передачей параметра).
Единственный логичный выход при использовании php тут — сделать header функцией с параметром title и вызывать через print_header($title).
А теперь представьте, ситуацию чуть сложнее: у вас есть шаблон главной, и вам надо сделать дочернюю страницу, заменив центральную часть, добавив пару блоков в правую колонку, подключить пару css-файлов в заголовке, добавить несколько ссылок в футер.
Ну? Будем резать шаблон на 10 кусков? Вводить кучу бессмысленных переменных типа $title, $right_column_bloks[], $footer_links[]. У вас есть решение для задачи, с которой сталкиваешься при разработке *любого* сайта, состоящего больше чем из одной страницы?
А завтра понадобится на всех страницах раздела новостей добавить в хедер баннер. Что? Будем добавлять переменную $is_news_template и выводить баннер через if?
Познакомьтесь уже с наследованием и потом без него обойтись не сможете :)
Почему это плохо? Потому что, задать название страницы я могу, только явно указав переменную title в контроллере, а в шаблоне я название задать не могу. Вариант типа [?php $title ='lalaa'; include 'header' ?] я даже не рассматриваю из-за неуклюжести (так как это имитация вызова функции с передачей параметра).
Единственный логичный выход при использовании php тут — сделать header функцией с параметром title и вызывать через print_header($title).
А теперь представьте, ситуацию чуть сложнее: у вас есть шаблон главной, и вам надо сделать дочернюю страницу, заменив центральную часть, добавив пару блоков в правую колонку, подключить пару css-файлов в заголовке, добавить несколько ссылок в футер.
Ну? Будем резать шаблон на 10 кусков? Вводить кучу бессмысленных переменных типа $title, $right_column_bloks[], $footer_links[]. У вас есть решение для задачи, с которой сталкиваешься при разработке *любого* сайта, состоящего больше чем из одной страницы?
А завтра понадобится на всех страницах раздела новостей добавить в хедер баннер. Что? Будем добавлять переменную $is_news_template и выводить баннер через if?
Познакомьтесь уже с наследованием и потом без него обойтись не сможете :)
НЛО прилетело и опубликовало эту надпись здесь
Хорошая статья, читал ее еще в оригинале. Не знаю, что подвигло Фабьена на такие резкие изменения, но буквально через какое-то время он еще решил убрать обратную совместимость с PHP 5.2 во второй версии symfony. Это, несомненно, большой шаг вперед, и симфони от этого только выиграет.
Даёшь XSLT в массы и точка. :)
Вы что, шутите? Это, получается, дизайнеру-верстальщику надо учить XSLT, который на порядок сложнее любого шаблонного языка, а программисту в контроллере генерировать XML (исключительно для того, чтобы потом с помощью XSLT его преобразовать в HTML). Да и само преобразование — процесс не особенно быстрый. И ради чего все это?
Искренне не понимаю людей, которые пытаются продвигать XSLT в качестве замены шаблонизаторам.
Искренне не понимаю людей, которые пытаются продвигать XSLT в качестве замены шаблонизаторам.
Люди думают, что раз так делают на джаве, то это круто.
Да и само преобразование — процесс не особенно быстрый
Докажете?
Я лично не занимался тестами скорости XSLT, но не сказал бы, что он в среднем медленнее традиционных «шаблонизаторов», написанных на интерпретируемых языках. Удобство и универсальность так или иначе пересиливает многие возможные его недостатки.
Я тоже тестами лично не занимался, но здравый смысл мне подсказывает, что разбирать и исполнять конструкции шаблонных языков куда проще, чем XSLT.
Скажите лучше что-нибудь по другим пунктам. Что в нем удобного-то? Он избыточно сложный и избыточно универсальный для такой задачи. Когда вам надо сделать список покупок в магазине, вы его в TeX верстаете, а потом заказываете печать в офсетной типографии?
Скажите лучше что-нибудь по другим пунктам. Что в нем удобного-то? Он избыточно сложный и избыточно универсальный для такой задачи. Когда вам надо сделать список покупок в магазине, вы его в TeX верстаете, а потом заказываете печать в офсетной типографии?
XSLT при генерации конечного результата использует нативные библиотеки, что уже даёт фору перед большинством шаблонизаторов, работающих на интерпретируемых языках.
Мне кажется насчёт сложности и избыточности — это всё стереотипы. Вы с ним имели дело хоть раз? Изучили парочку простейших шаблонов? Никто же не заставляет вас изучать абсолютно каждую существующую возможность XSL преобразований досконально, чтобы решать какие-то простейшие задачи. Это удобно даже для сайтов из десятка страниц, а главное — очень гибко и отлично масштабируется при первой необходимости.
Мне кажется насчёт сложности и избыточности — это всё стереотипы. Вы с ним имели дело хоть раз? Изучили парочку простейших шаблонов? Никто же не заставляет вас изучать абсолютно каждую существующую возможность XSL преобразований досконально, чтобы решать какие-то простейшие задачи. Это удобно даже для сайтов из десятка страниц, а главное — очень гибко и отлично масштабируется при первой необходимости.
Работал с XSLT немного (верстка для HostCMS), по-моему главный его недостаток в том, что неудобно читать шаблоны — мешанина из тэгов (разные пространства имен не спасают).
Ну, смотря как шаблон написан.
Вы в лабу по Си одногрупнику смотрели? Там тоже мешанина, и что же теперь, Си плохой?
Вы в лабу по Си одногрупнику смотрели? Там тоже мешанина, и что же теперь, Си плохой?
Синтаксис Си плохой, устаревший, зачастую двусмысленный, склонный к ошибкам (знаете, почему пишут if (0 == x), а не наоборот?), требующий очень много букв на то, что в других языках делается одной строчкой. Плюс там нет модулей и надо руками писать заголовочные файлы, определять функции до объявления (делать одну и ту же работу 2 раза фактически). и еще много чего. Почитайте, например у автора языка D ( www.digitalmars.com/d/2.0/overview.html ), какие недостатки он нашел в Си.
Я не говорил что XSLT плохой, преимущества у него есть и их глупо отрицать. Но вот синтаксис удобным назвать нельзя и в больших шаблонах получается действительно мешанина.
Для примера, часть реального шаблона: pastebin.org/55704
Удобно? Понятно? Мне — нет.
Для примера, часть реального шаблона: pastebin.org/55704
Удобно? Понятно? Мне — нет.
Похоже вы его не умеете готовить, об этом говорит множество xsl:variable, использование рекурсивного вызова шаблона там где это не нужно. Подготовьте данные для пейджера в PHP, и заставьте шаблонизатор лишь вывести их.
Это шаблон из бесплатной редакции HostCMS, т.е. реальный пример того с чем придется столкнуться при работе XSLT.
Это лишь говорит об уровне программистов HostCMS. Вот поэтому XSLT и не прет, просто большинство программистов пытаются на нем писать императивно, а потом жалуются что ерунда получается. Замечено не раз, кстати.
Эта мания заводить побольше xsl:variable идет от привычки все держать в переменных, которых в XSLT на самом деле нет. Так же признаком неумения делать XSLT шаблоны является частое использование именованных шаблонов <xsl:template name="">
На месте программистов HostCMS я бы просто сформировал узлы
и потом просто бы вывел:
Эта мания заводить побольше xsl:variable идет от привычки все держать в переменных, которых в XSLT на самом деле нет. Так же признаком неумения делать XSLT шаблоны является частое использование именованных шаблонов <xsl:template name="">
На месте программистов HostCMS я бы просто сформировал узлы
<pages><page>1</page><page>2</page><page>3</page></pages>
и потом просто бы вывел:
<template match="pages>
<xsl:for-each select="page">
<a href="{/document/forums_path}{/document/forums_id}/{theme_id}/page-{.}/">
<xsl:value-of select="."/>
</a>
</xsl:for-each>
</template>Я с Вами согласен, разве что забыли добавить пометку активной страницы.
Но почему-то мне кажется, что большинство напишет как в первом примере (если приложения не только для себя это рано или поздно случится, т.к. проверять всех кто правит шаблоны не будешь). Разбираться в подобных шаблонах у меня желания нет, т.е. для себя я сделал вывод: в тех приложениях где нельзя гарантировать определенный уровень XSLT верстальщика (а они есть?) предпочтительнее обычный шаблонизатор.
Но почему-то мне кажется, что большинство напишет как в первом примере (если приложения не только для себя это рано или поздно случится, т.к. проверять всех кто правит шаблоны не будешь). Разбираться в подобных шаблонах у меня желания нет, т.е. для себя я сделал вывод: в тех приложениях где нельзя гарантировать определенный уровень XSLT верстальщика (а они есть?) предпочтительнее обычный шаблонизатор.
НЛО прилетело и опубликовало эту надпись здесь
Расскажите кому-нибудь про хороший PHP, и про ошибки, которые на нем делаются. Однако это не мешает делать на нем отличные сайты, правда для этого приходится учиться.
А XSLT, кстати, позволяет избежать множества ошибок. Даже делая тест скорости шаблонизаторов, я обнаружил ошибки HTML кода в малюсеньком PHP тесте. Всевозможные XSS дыры на сайтах появляются благодаря хорошему языку? На XSLT сайте встретить такое можно гораздо реже, т.к. архитектура языка не позволяет такие ошибки делать по-умолчанию. Хотя конечно здесь может быть просто выше порог входа.
Заметил, что если шаблон не дал ошибку сразу, то он будет работать в любых ситуациях, в отличие от других шаблонизаторов, он посчитает и деление на ноль (получится бесконечность), и не упадет при обращении к несуществующему индексу в массиве.
В том же PHP чтобы исключить полностью SQL-инъекции, достаточно просто применять PDO для работы с базами данных. Но, насколько могу судить по исходным кодам разных проектов, эта библиотека применяется крайне редко. Парадокс.
А XSLT, кстати, позволяет избежать множества ошибок. Даже делая тест скорости шаблонизаторов, я обнаружил ошибки HTML кода в малюсеньком PHP тесте. Всевозможные XSS дыры на сайтах появляются благодаря хорошему языку? На XSLT сайте встретить такое можно гораздо реже, т.к. архитектура языка не позволяет такие ошибки делать по-умолчанию. Хотя конечно здесь может быть просто выше порог входа.
Заметил, что если шаблон не дал ошибку сразу, то он будет работать в любых ситуациях, в отличие от других шаблонизаторов, он посчитает и деление на ноль (получится бесконечность), и не упадет при обращении к несуществующему индексу в массиве.
В том же PHP чтобы исключить полностью SQL-инъекции, достаточно просто применять PDO для работы с базами данных. Но, насколько могу судить по исходным кодам разных проектов, эта библиотека применяется крайне редко. Парадокс.
НЛО прилетело и опубликовало эту надпись здесь
В том же PHP чтобы исключить полностью SQL-инъекции, достаточно просто применять PDO для работы с базами данных. Но, насколько могу судить по исходным кодам разных проектов, эта библиотека применяется крайне редко. Парадокс.
Достаточно mysqli, PDO — больше на объектах завязано. Хотя принципиально разницы нет конечно.
В XSLT одно и тоже преобразование можно написать десятком путей. Поэтому мы можем говорить и о архитектуре шаблона.
И новичёк, не имея хороших примеров перед собой, соответсвенно, совершает архитектурные ошибки. И выглядит это уродски. А совершает он их по простой причине того, что думает, что всё программирование императивно.
Должен ли быть сделан язык шаблонизатора так, чтобы исключить архитектурные ошибки новичков? Я считаю, не должен.
И новичёк, не имея хороших примеров перед собой, соответсвенно, совершает архитектурные ошибки. И выглядит это уродски. А совершает он их по простой причине того, что думает, что всё программирование императивно.
Должен ли быть сделан язык шаблонизатора так, чтобы исключить архитектурные ошибки новичков? Я считаю, не должен.
habrahabr.ru/blogs/xslt/47545/
В конце мой шаблон, предназначенный для того же, что и у вас по ссылке. По моему вполне читабельно получилось…
В конце мой шаблон, предназначенный для того же, что и у вас по ссылке. По моему вполне читабельно получилось…
перенастройте подсветку синтаксиса :)
впрочем, я и без оной не испытываю неудобств с XSL, главное — привыкнуть
впрочем, я и без оной не испытываю неудобств с XSL, главное — привыкнуть
Ну давайте сравним на простейшем примере, никаких стереотипов:
Нормальный шаблонизатор:
{% for item in items %}
* {{ item }}
{% endfor %}
XSLT:
<xsl:template match=«items»>
<xsl:apply-templates/>
</xsl:template>
<xsl:template match=«item»>
* <xsl:apply-templates/>
</xsl:template>
Мало того, что символов втрое больше, так это и выглядит совершенно нечитаемо для верстальщика. И это самая простейшая задача. Что в этом удобного? Ну или я не знаю, я не специалист по XSLT, может быть это проще сделать можно?
И еще такой вопрос: в цепочке «данные -> XML -> HTML» для чего нужен XML? Только для того, чтобы можно было воспользоваться XSLT? Все это, повторюсь, попахивает несоответствием инструмента задаче.
Я не говорю, что XSLT — какой-то сверхнепонятный язык, который кто-то не в состоянии постичь; в любой технологии можно разобраться, затратив на это определенное время, и после этого она перестанет казаться непонятной. Суть моих претензий, во-первых, в несоразмерности задачи и усилий, затрачиваемых на знакомство с технологией, во-вторых, в синтаксической и семантической избыточности XSLT при использовании в шаблонах сайтов, а в-третьих, в несоответствии технологии задаче (зачем мне XSLT, если у меня нет XML, а есть реляционная БД?)
Нормальный шаблонизатор:
{% for item in items %}
* {{ item }}
{% endfor %}
XSLT:
<xsl:template match=«items»>
<xsl:apply-templates/>
</xsl:template>
<xsl:template match=«item»>
* <xsl:apply-templates/>
</xsl:template>
Мало того, что символов втрое больше, так это и выглядит совершенно нечитаемо для верстальщика. И это самая простейшая задача. Что в этом удобного? Ну или я не знаю, я не специалист по XSLT, может быть это проще сделать можно?
И еще такой вопрос: в цепочке «данные -> XML -> HTML» для чего нужен XML? Только для того, чтобы можно было воспользоваться XSLT? Все это, повторюсь, попахивает несоответствием инструмента задаче.
Я не говорю, что XSLT — какой-то сверхнепонятный язык, который кто-то не в состоянии постичь; в любой технологии можно разобраться, затратив на это определенное время, и после этого она перестанет казаться непонятной. Суть моих претензий, во-первых, в несоразмерности задачи и усилий, затрачиваемых на знакомство с технологией, во-вторых, в синтаксической и семантической избыточности XSLT при использовании в шаблонах сайтов, а в-третьих, в несоответствии технологии задаче (зачем мне XSLT, если у меня нет XML, а есть реляционная БД?)
Хочу заметить, что длинно или коротко — не всегда важно, все зависит от качества подсветки и автодополнения кода в редакторе. (Хотя, конечно, идеального редактора для XSLT-шаблонов я пока не видел; ближайший кандидат для меня — XML Spy для Eclipse, но он платный.)
Кстати, for не эквивалентен xsl:template. Лучше уж сравнивать for и xsl:for-each. Лично моя практика показывает, что xsl:template в основном используется для определения именованных блоков, подверженных наследованию, т.е. для того же, что есть в Джанге. А с использованием ShortXSLT for-each и вовсе записывается вот так:
{for-each /nodes/*}
Name: {./name}
{/for-each}
Кстати, for не эквивалентен xsl:template. Лучше уж сравнивать for и xsl:for-each. Лично моя практика показывает, что xsl:template в основном используется для определения именованных блоков, подверженных наследованию, т.е. для того же, что есть в Джанге. А с использованием ShortXSLT for-each и вовсе записывается вот так:
{for-each /nodes/*}
Name: {./name}
{/for-each}
Я просто понять не могу, зачем нужны все эти сложности с генерированием промежуточного XML, использованием надстроек-компиляторов для XSLT, изучением не самого простого языка, если есть простой и удобный способ. Да, есть весьма ограниченный круг задач, когда этот самый промежуточный XML может еще где-то пригодиться, но в большинстве случаев он никому не нужен.
Эх… дался Вам этот промежуточный XML. :-) И потом, почему ИМЕННО ЭТОТ промежуточный слой вызывает столько вопросов? Чтобы его закодировать, нужно всего-то 30 строк кода. А ведь есть еще другие, более грандиозные, слои: это сам интерпретатор PHP, парсер PHP во внутреннее представление, написанный на Yacc + Bison (или Lex, не помню точно), который компилируется программу на Си, которая обрабатывается препроцессором cc, который подается на вход gcc, из которого gcc делает внутреннее платформенно-независимое представление, которое превращается в объектный файл, который отдается на вход линковщику, который запускается в отдельном адресном пространстве, выделенном ОС, которая написана на Си, который написан на более старом Си, который написан на еще более старом Си, который ..., который написан на ассемблере, который написан на более старом ассемблере, который ..., который написан в машинных кодах. (Уверен, что я еще потерял по дороге добрую сотню промежуточных слоев, ну да ладно.)
Эти слои абстракты и мы никак не может на них повлиять, если только не сделать форк, либо выбрать другой язык. XML более чем реален и от него еще более реально можно отказаться (в шаблонах).
Блин, PHP-шаблонизаторы генерируют PHP-код, который исполняется, может быть закеширован опкешером, а XSLT — это обработка, парсинг 2 (!) XML-файлов, сложные преобразования, и кешировать тут просто нечего (разве что можно шаблон преобразовать в дерево и сохранить сериализованную версию, но все равно эт намного менее оптимально).
И писать в контроллере $this->set(array('a' => 6, 'b' => 7)) куда как проще, чем добавлять вызовы для генерации Xml (еще лишние тормоза).
И да, читать XML человеку практически невозможно, ни с какой подсветкой, так как слишком многог букв и лишних значков. Ну и набирать дольше, а про IDE — это вообще смешно, получается я без тяжелой тормозной иды не могу теперь файл нормально редактирвоать? Извольте, сударь, я как-нибудь без этого обойдусь)
И писать в контроллере $this->set(array('a' => 6, 'b' => 7)) куда как проще, чем добавлять вызовы для генерации Xml (еще лишние тормоза).
И да, читать XML человеку практически невозможно, ни с какой подсветкой, так как слишком многог букв и лишних значков. Ну и набирать дольше, а про IDE — это вообще смешно, получается я без тяжелой тормозной иды не могу теперь файл нормально редактирвоать? Извольте, сударь, я как-нибудь без этого обойдусь)
PHP код точно так же обрабатывается интерпретатором, как и из текстового XML собирается DOM в памяти. Нужно просто знать, что DOM это накладно по памяти, и не подсовывать гигантские XML файлы.
Я делаю сразу XSLT шаблоны без всякой компилирующей прослойки, использую обычный текстовый редактор с подсветкой синтаксиса — Geany, этот редактор также умеет сворачивать деревья, хотя для обычных шаблонов даже этого не нужно.
Для формирования XML используйте SimpleXml, из PHP данные выглядят как обычный объект, можно использовать XPath для хождения по дереву, и в конце выгрузить XML в DOM и произвести XSLT трансформацию (получается быстрее чем формировать сразу DOM).
Из базы данных все равно нужно во что-то преобразовывать, это могут быть свои объекты, массивы, я же использую вышеназванный SimpleXml.
Если не можете читать XML, то как же вы читаете HTML? Шаблоны XSLT это не самые большие файлы проекта, набирать их не сложно, дело лишь в привычке. Если же хотите сэкономить для своих пальцев пару килобайт кода, то воспользуйтесь какой-нибудь компилирующей библиотекой для XML/XSLT. Не могу посоветовать какой именно, т.к. ни одну не использовал в деле за ненадобностью.
Я делаю сразу XSLT шаблоны без всякой компилирующей прослойки, использую обычный текстовый редактор с подсветкой синтаксиса — Geany, этот редактор также умеет сворачивать деревья, хотя для обычных шаблонов даже этого не нужно.
Для формирования XML используйте SimpleXml, из PHP данные выглядят как обычный объект, можно использовать XPath для хождения по дереву, и в конце выгрузить XML в DOM и произвести XSLT трансформацию (получается быстрее чем формировать сразу DOM).
Из базы данных все равно нужно во что-то преобразовывать, это могут быть свои объекты, массивы, я же использую вышеназванный SimpleXml.
Если не можете читать XML, то как же вы читаете HTML? Шаблоны XSLT это не самые большие файлы проекта, набирать их не сложно, дело лишь в привычке. Если же хотите сэкономить для своих пальцев пару килобайт кода, то воспользуйтесь какой-нибудь компилирующей библиотекой для XML/XSLT. Не могу посоветовать какой именно, т.к. ни одну не использовал в деле за ненадобностью.
Вы сейчас человеку, который не хочет съесть не кактус, а пирожок, советуете как все-таки лучше съесть кактус. Мол, нужно выбирать кактусы с иголками помягче, приглаживать их к поверхности перед едой, и еще можно немного в микроволновке подогреть. Тогда совершенно ничего страшного в этом и не будет. Но вопрос-то при этом никуда не девается — зачем глотать кактус, когда есть пирожок?
Ну для кого это и кактус, а для кого и пирожок. Я вот использую XSLT уже очень с давних пор, когда его в PHP еще и не было. Другие шаблонизаторы смотрел, но не находил удобного для себя, все они слишком перегружены функциями, и не умеют нормально работать с деревьями.
И если человек не зная XSLT утверждает что он кривой, то он явно не прав. Понятно что его научить с таким подходом невозможно, но пускай других не вводит в заблуждение. Раз сам не осилил, то это не значит что не осилят другие.
И если человек не зная XSLT утверждает что он кривой, то он явно не прав. Понятно что его научить с таким подходом невозможно, но пускай других не вводит в заблуждение. Раз сам не осилил, то это не значит что не осилят другие.
Не надо меня выставлять идиотом, я в состоянии осилить XSLT, несколько лет назад писал несколько шаблонов и вполне представляю, что это такое. Я не говорю, что он кривой; я полностью согласен с тем, что XSLT — мощный и универсальный инструмент. Но это не повод применять его везде.
Вы бы еще предложили писать сайты на Хаскелле, он же тоже функциональный, и вообще такой изящный и абстрактный.
Вы бы еще предложили писать сайты на Хаскелле, он же тоже функциональный, и вообще такой изящный и абстрактный.
> Для формирования XML используйте SimpleXml, из PHP данные выглядят как обычный объект, можно использовать XPath для хождения по дереву, и в конце выгрузить XML в DOM и произвести XSLT трансформацию (получается быстрее чем формировать сразу DOM).
Все эти лишние раширения только прибавляют тормозов. Добавить элемент в массив или извлечь оттуда куда как быстрее и не требует никаких расширений.
Я понимаю, что вас видимо впечатляет универсальность XML, например меня в свое время удивил пример, приведенный где-то у Лебедева — они хранят номера телефонов с кодом города как XML-элементы, и при выводе могут отображать их в произвольном формате.
Но все же там, где я сталкивался, такая универсальность была излишней. Потому использовать php-шаблонизаторы (для меня) проще и удобнее.
Все эти лишние раширения только прибавляют тормозов. Добавить элемент в массив или извлечь оттуда куда как быстрее и не требует никаких расширений.
Я понимаю, что вас видимо впечатляет универсальность XML, например меня в свое время удивил пример, приведенный где-то у Лебедева — они хранят номера телефонов с кодом города как XML-элементы, и при выводе могут отображать их в произвольном формате.
Но все же там, где я сталкивался, такая универсальность была излишней. Потому использовать php-шаблонизаторы (для меня) проще и удобнее.
Меня впечатляет не только универсальность и распространенность на всех платформах, но и удобство работы с деревьями, оси навигации. Насчет тормозов, я сейчас делаю форумный движок со сложным выводом древовидных комментариев, в нем используется XSLT, так он быстрее в 2 раза чем phpbb3, в котором примитивные плоские комментарии, и очередной нестандартный шаблонизатор.
Если я и теряю в производительности где-то, то выиграю в другом, в итоге получается как минимум не медленней, чем даже чистое PHP решение. Речь конечно идет о чем-нибудь сложнее простой домашней странички, где вообще шаблонизатор не нужен.
Любой из предлагаемых шаблонизаторов будет по объему кода больше чем мой проект в несколько раз, поэтому использовать их смысла нет, ведь XSLT уже встроен в PHP, и, в отличие от этих шаблонизаторов, не содержит ошибок.
Если я и теряю в производительности где-то, то выиграю в другом, в итоге получается как минимум не медленней, чем даже чистое PHP решение. Речь конечно идет о чем-нибудь сложнее простой домашней странички, где вообще шаблонизатор не нужен.
Любой из предлагаемых шаблонизаторов будет по объему кода больше чем мой проект в несколько раз, поэтому использовать их смысла нет, ведь XSLT уже встроен в PHP, и, в отличие от этих шаблонизаторов, не содержит ошибок.
> так он быстрее в 2 раза чем phpbb3
Вы бы еще написали «быстрее чем Друпал». Сравнивать с кое-как на коленке написанным решением нечестно. Тем более, что phpbb — старый проект, со всеми вытекающими.
Так что, насчет универсальности и древовидных структур я спорить не буду, а вот в то, что XSLT быстрее, не поверю :(
Вы бы еще написали «быстрее чем Друпал». Сравнивать с кое-как на коленке написанным решением нечестно. Тем более, что phpbb — старый проект, со всеми вытекающими.
Так что, насчет универсальности и древовидных структур я спорить не буду, а вот в то, что XSLT быстрее, не поверю :(
Он не везде быстрее, вот для обработки деревьев лучше нет, и быстрее программировать, и работает очень шустро. Я тестировал скорость XSLT по сравнению с нативным PHP и Smarty, XSLT оказался ближе к PHP, и довольно ощутимо опередил Smarty. Пример с phpbb привел, так как только что вышла новая версия, ведь этот движок считается не медленным. После сравню с другими движками, более быстрыми и современными.
Почему тормозит смарти — я понял, очевидно, из-за того, что там инклюдится довольно-таки большой Smarty.class.php, и генерируется довольно-таки неуклюжий шаблон, а вот почему XSLT ненамного медленнее php — понять не могу, это как-то странно ((
Возможно, дело в не-использовании кешера опкодов, из-за чего в примере с php-шаблонизаторами интерпретатору приходилось каждый раз их заново парсить.
Надеюсь, в новых версиях php исправят баги с производителностью, и ваш XSLT займет заслуженное последнее место :)
Возможно, дело в не-использовании кешера опкодов, из-за чего в примере с php-шаблонизаторами интерпретатору приходилось каждый раз их заново парсить.
Надеюсь, в новых версиях php исправят баги с производителностью, и ваш XSLT займет заслуженное последнее место :)
Этот XML кешировать клево))
Используйте SimpleXml, с ним и удобно работать, и удобно из него данные брать в самом PHP. Плюс еще есть возможность использовать XPath. Оси навигации в XPath это очень классная штука. Да и функциональный принцип программирования, что в XSLT, для шаблонов лучше подходит. Ну и то что XSLT есть на всех платформах, добавляет такой жирный плюс, каким ни один из существующих шаблонизаторов не сможет похвастаться.
Купите нормальную книгу, постарайтесь разобраться как правильно писать шаблоны на XSLT, вот тогда он понравится очень сильно.
Купите нормальную книгу, постарайтесь разобраться как правильно писать шаблоны на XSLT, вот тогда он понравится очень сильно.
Вот мой комментарий, habrahabr.ru/blogs/php/75901/?reply_to=2203909#comment_2203960
Вы можете предложить какие-то техники по ускорению XSLT? По повышению удобства работы с нечитаемыми XML-шаблонами?
Вы можете предложить какие-то техники по ускорению XSLT? По повышению удобства работы с нечитаемыми XML-шаблонами?
Ответил там по тому комментарию.
Ускорение какого рода имеете ввиду, разработки, выполнения?
По поводу удобства, похоже что это дело привычки, я вот не могу читать PHP нативный шаблон (<?php code ?> и <?= env ?>), да и всякие другие нестандартные виды шаблонов, просто не работал с ними.
Ускорение какого рода имеете ввиду, разработки, выполнения?
По поводу удобства, похоже что это дело привычки, я вот не могу читать PHP нативный шаблон (<?php code ?> и <?= env ?>), да и всякие другие нестандартные виды шаблонов, просто не работал с ними.
Для меня, конечно важно ускорение разработки (за счет удобного синтаксиса), но скорость выполнения все же важнее :)
По поводу синтаксиса, вот пример (угловые скобки я заменил на квадратные, позор парсеру хабра):
[a href=«articles/{$article.id|escape:url}.html»]ссылка[/a]
(Модификатор escape:url экранирует не-буквенно-цифоровые символы в названии статьи, заменяя их на знак процента с hex=кодом символа). Разве это сложно? Разве на Xml это будет проще, а?
Поверьте, Xml освоить куда как сложнее того же Twig, Smarty или dwoo :)
По поводу синтаксиса, вот пример (угловые скобки я заменил на квадратные, позор парсеру хабра):
[a href=«articles/{$article.id|escape:url}.html»]ссылка[/a]
(Модификатор escape:url экранирует не-буквенно-цифоровые символы в названии статьи, заменяя их на знак процента с hex=кодом символа). Разве это сложно? Разве на Xml это будет проще, а?
Поверьте, Xml освоить куда как сложнее того же Twig, Smarty или dwoo :)
Ну вот, докатились, только для того, чтобы написать правильный шаблон, уже нужно покупать книгу.
Ну не используйте тогда XSLT, кто же заставляет то? И CSS не используйте, его же тоже нужно изучать.
Ну как же, адепты XSLT в этой ветке уверяют, что XSLT — это лучшее решения для шаблонов в проектах любого масштаба. Просто объясните, зачем усложнять вещи, которые МОГУТ быть простыми? KISS ведь и все такое.
C CSS сравнение некорректно, потому что альтернатива CSS — это кашеобразный HTML с атрибутами и без возможности повторно использовать стили, а альтернатива XSLT в контексте нашего разговора — простые и читаемые шаблоны. И не надо сравнивать сложность CSS и XSLT.
C CSS сравнение некорректно, потому что альтернатива CSS — это кашеобразный HTML с атрибутами и без возможности повторно использовать стили, а альтернатива XSLT в контексте нашего разговора — простые и читаемые шаблоны. И не надо сравнивать сложность CSS и XSLT.
Вполне корректное сравнение, оба этих языка (CSS и XSLT) декларативные. А предлагаемые шаблоны используются лишь на одной платформе (PHP), и не настолько они и читаемы (например для меня), это лишь дело привычки. Если бы все было просто, то не выдумывали бы шаблоны вообще, пользовались бы нативным PHP, но нет же, развелось их целый воз и маленькая тележка.
Я изучал XSLT, когда еще программировал на другой платфомре, тогда в PHP его и в помине не было. Сейчас же (полтора года назад) с легкостью перешел на PHP именно благодаря XSLT, ведь мне не нужно изучать еще и синтаксис не пойми какого шаблонизатора, а то и нескольких, чтобы узнать какой из них лучше.
Сравниваю еще с CSS, т.к. он посложнее будет чем XSLT, но его все равно придется изучать. И никто не пытается впаривать всем свой заменитель, основанный на JS, например.
Я изучал XSLT, когда еще программировал на другой платфомре, тогда в PHP его и в помине не было. Сейчас же (полтора года назад) с легкостью перешел на PHP именно благодаря XSLT, ведь мне не нужно изучать еще и синтаксис не пойми какого шаблонизатора, а то и нескольких, чтобы узнать какой из них лучше.
Сравниваю еще с CSS, т.к. он посложнее будет чем XSLT, но его все равно придется изучать. И никто не пытается впаривать всем свой заменитель, основанный на JS, например.
Корректность сравнения зависит от контекста сравнения и особенностей сравниваемых сущностей в этом контексте, а не от того, что оба языка декларативные. Я вам объяснил, что у CSS нет альтернатив, а у XSLT — есть.
Предлагается не какой-то конкретный шаблонизатор, а подход. Этот подход имеет свои реализации на любой веб-платформе — PHP, Python(Django/Pylons), RoR. Они все настолько простые, что для того, чтобы в них разобраться, нужно минут 10 (на прочтение 1 страницы с документацией).
Предлагается не какой-то конкретный шаблонизатор, а подход. Этот подход имеет свои реализации на любой веб-платформе — PHP, Python(Django/Pylons), RoR. Они все настолько простые, что для того, чтобы в них разобраться, нужно минут 10 (на прочтение 1 страницы с документацией).
Из редакторов XML (в т.ч. XSLT) мне всегда очень нравился Stylus Studio, но он тоже платный…
Конечно же, реляционные БД можно быстро отображать с помощью Пыха напрямую, но XSLT дает универсальную возможность преобразования структурированных данных в любую последовательность отображаемых данных. И в связке Data -> XML -> HTML могут появится при абстрактных задачах связки вида: Data -> XML -> Data, HTML -> XML -> Data, XML->XML->Data, XML -> XML -> HTML и тд и тп.
Все зависит от Ваших задач. Скорость или универсальность? Выбирать Вам!
Все зависит от Ваших задач. Скорость или универсальность? Выбирать Вам!
Я и не спорю, что есть задачи, когда XSLT — подходящий инструмент. Например, выдача Яндекса, которая может показываться на самом Яндексе, а может отдаваться через Яндекс.XML. В таких случаях это действительно оправдано. Но когда речь идет о не очень больших сайтах, для которых нету необходимости все выходные данные предоставлять в нескольких форматах, я не вижу ни одной причины для использования XSLT. А таких сайтов в Интернете, наверное, 95%.
И только тот факт, что XSLT универсален и стандартизован, не делает его лучшим решением во всех случаях.
И только тот факт, что XSLT универсален и стандартизован, не делает его лучшим решением во всех случаях.
Мне например, удобнее всего передавать данные в виде одного большого PHP-массива, и такой способ никак не мешает добавлять дополнительные преобразования, но лишен недостатков в виде тормознутости и нечитаемости XML.
зачем мне XSLT, если у меня нет XML, а есть реляционная БД
Как будто вы в случае с традиционными шаблонизаторами сразу имеете возможность отправить результат произвольного SQL запроса в шаблон. Если даже где-то такое и предусмотрено — тут попахивает всевозможными косяками.
Сделать автогенерацию XML дерева на основе результата запроса — пара пустяков. Более того, с таким универсальным решением задачу по минимальному преобразованию и отрисовке результатов можно переложить целиком на XSL шаблон.
Приведённый вами пример или испорчен парсером Хабра, или вы не имеете даже базового представления об XSL.
>Сделать автогенерацию XML дерева на основе результата запроса — пара пустяков.
Помню первый свое XML дерево построил на базе SMARTY :)
>Более того, с таким универсальным решением задачу по минимальному преобразованию и отрисовке результатов можно переложить целиком на XSLT шаблон.
После этого только один браузер из тестирируемых заставил отобразить связку XML+XSLT (сейчас, наверное, дела получше, но ИЕ6 еще есть).
>или вы не имеете даже базового представления об XSL.
Могу прикинуть, что базовое представление такое же как у меня — то есть изучал когда-то давно из интереса к новым технологиям по статье в каком-нибудь журнале и по справке встроенной в DreamWeaver
Помню первый свое XML дерево построил на базе SMARTY :)
>Более того, с таким универсальным решением задачу по минимальному преобразованию и отрисовке результатов можно переложить целиком на XSLT шаблон.
После этого только один браузер из тестирируемых заставил отобразить связку XML+XSLT (сейчас, наверное, дела получше, но ИЕ6 еще есть).
>или вы не имеете даже базового представления об XSL.
Могу прикинуть, что базовое представление такое же как у меня — то есть изучал когда-то давно из интереса к новым технологиям по статье в каком-нибудь журнале и по справке встроенной в DreamWeaver
Уже давно некоторые браузеры научились обрабатывать XSLT, но до сих пор это не применяется на практике из-за недостаточной поддержки всеми современными браузерами.
Поэтому XSLT применяется на сервере, после трансформации данные отдаются браузеру в HTML или XHTML виде, и тут уж любой браузер отображает их нормально.
Поэтому XSLT применяется на сервере, после трансформации данные отдаются браузеру в HTML или XHTML виде, и тут уж любой браузер отображает их нормально.
Вовсе не обязательно непосредственный результат из SQL запроса отправлять в шаблон. Суть в том, что мои исходные данные не представлены в XML, и чтобы воспользоваться XSLT, мне надо искусственно генерировать XML, который мне больше не нужен ни для каких целей. При этом я еще и теряю возможность передавать в шаблон объекты. Вот вам другой пример:
{% for comment in post.comments %}
{{ comment.short_text }}
{% endfor %}
Чтобы это реализовать на XSLT, мне сначала придется сгенерировать руками XML (никакой рекурсивный обход массивов или автогенерация мне не поможет, потому что short_text — это метод), а потом еще и XSLT-шаблон написать. И зачем это нужно? Никто еще не привел ни одного убедительного плюса XSLT, кроме того, что промежуточный XML можно еще куда-нибудь приткнуть.
{% for comment in post.comments %}
{{ comment.short_text }}
{% endfor %}
Чтобы это реализовать на XSLT, мне сначала придется сгенерировать руками XML (никакой рекурсивный обход массивов или автогенерация мне не поможет, потому что short_text — это метод), а потом еще и XSLT-шаблон написать. И зачем это нужно? Никто еще не привел ни одного убедительного плюса XSLT, кроме того, что промежуточный XML можно еще куда-нибудь приткнуть.
посмотрите выставку cebit2009, какие проекты там представлены и в каких используется XSLT!
XSLT является стандартом по дефалту в .NET…
Если вы не в состоянии понять плюсы использования XSLT — не используйте его, вопрос лишь в том, что будете ездить на квадратных колесах с горе шаблонитизаторами на PHP
XSLT является стандартом по дефалту в .NET…
Если вы не в состоянии понять плюсы использования XSLT — не используйте его, вопрос лишь в том, что будете ездить на квадратных колесах с горе шаблонитизаторами на PHP
XSLT промышленный стандарт! XSLT используется для гораздо более сложных проектов чем сайты на PHP… Про мелкие задачи — грех обсуждать…
а скриптовые шаблонитизаторы для PHP — отход от принципов веба — тэги!
а скриптовые шаблонитизаторы для PHP — отход от принципов веба — тэги!
Я тестировал скорость XSLT относительно простого PHP и Smarty, оказался довольно шустрым, особенно если использовать SimpleXml для подготовки данных.
А то толкают уже давно миф что XSLT медленный, видимо выгружали всю базу в XML, и хотели чего-то выдающегося увидеть.
А то толкают уже давно миф что XSLT медленный, видимо выгружали всю базу в XML, и хотели чего-то выдающегося увидеть.
XSLT — универсальный паттерн, описывающий шаблонизатор. Во-первых, он универсален, во-вторых, он страндартизован, в-третьих, на вход поступают структурированные данные. Что еще надо?
По поводу XSLT, XML и сокращенных тэгов.
1. Не нужно, конечно же, генерировать XML в контроллерах, откуда эта фантазия? В контроллерах можно генерировать нативный PHP-массив, который несложной рекурсивной функцией автоматически преобразуется в XML, а тот уже подается на вход XSLT. В итоге, хоть XML и есть, но нигде в коде он явно не генерируется. А отлаживать шаблоны и предоставлять внешние API удобно.
2. С многословностью XSLT лично я борюсь вот так: dklab.ru/lib/Dklab_ShortXSLT/ — это надстройка-компилятор над XSLT, которая компилирует шаблоны в XSLT. Важно, что компиляция происходит «на лету» и с кэшированием получившихся xslt-файлов, поэтому это не дает накладных расходов (своеобразный «JIT в XSLT»). Также никто не запрещает из XSLT вызывать специальные PHP-хелперы (например, для обращения к роутеру).
3. Искренне не понимаю людей, которые пишут <?php echo $a?> вместо <?=$a?>. На хостинге отключены короткие тэги? Ну так включите их в .htaccess или же воспользуйтесь функцией ini_set(«short_open_tag», true) во фронт-контроллере. Не можете написать <?xml ...?>? Ну так напишите <?='<?xml version="..."?>'?>, неужели так много мест, где это потребуется написать? Применяете PHP-вставки в XML-документах? А я предпочитаю XML-документы генерировать программно, а также с помощью XSLT.
Да, еще одно. В Смарти давным-давно имеется режим автоквотинга, только он по умолчанию выключен. (Я сам Смарти не очень люблю.)
1. Не нужно, конечно же, генерировать XML в контроллерах, откуда эта фантазия? В контроллерах можно генерировать нативный PHP-массив, который несложной рекурсивной функцией автоматически преобразуется в XML, а тот уже подается на вход XSLT. В итоге, хоть XML и есть, но нигде в коде он явно не генерируется. А отлаживать шаблоны и предоставлять внешние API удобно.
2. С многословностью XSLT лично я борюсь вот так: dklab.ru/lib/Dklab_ShortXSLT/ — это надстройка-компилятор над XSLT, которая компилирует шаблоны в XSLT. Важно, что компиляция происходит «на лету» и с кэшированием получившихся xslt-файлов, поэтому это не дает накладных расходов (своеобразный «JIT в XSLT»). Также никто не запрещает из XSLT вызывать специальные PHP-хелперы (например, для обращения к роутеру).
3. Искренне не понимаю людей, которые пишут <?php echo $a?> вместо <?=$a?>. На хостинге отключены короткие тэги? Ну так включите их в .htaccess или же воспользуйтесь функцией ini_set(«short_open_tag», true) во фронт-контроллере. Не можете написать <?xml ...?>? Ну так напишите <?='<?xml version="..."?>'?>, неужели так много мест, где это потребуется написать? Применяете PHP-вставки в XML-документах? А я предпочитаю XML-документы генерировать программно, а также с помощью XSLT.
Да, еще одно. В Смарти давным-давно имеется режим автоквотинга, только он по умолчанию выключен. (Я сам Смарти не очень люблю.)
2. Речь идет о шаблонах. Чем использование вашего ShortXSLT принципиально лучше нативного php? Зачем сперва строить xml, а потом тратить время на его преобразование? Где профит???
Профит в том, что этот XML можно вывести в чистом виде для "'экспресс-дебага" или предоставления примитивного API, можно одним шаблоном преобразовать в HTML, другим в XHTML, третьим — в RSS, четвертым в ATOM, пятым в PDF, шестым в SVG ))) Можно и в JSON, мне пока не приходилось…
Отмечу особо, что можно вывести в чистом XML без шаблона… Это на самом деле ОЧЕНЬ удобно когда перед тобой все входные данные безо всяких var_dump и пр. костылей
Отмечу особо, что можно вывести в чистом XML без шаблона… Это на самом деле ОЧЕНЬ удобно когда перед тобой все входные данные безо всяких var_dump и пр. костылей
Плюс этот XML удобно кешировать (причем по-кусочкам)
Почему php-массив с данными лучше XML-файла? Он хранится в бинарном виде, его не надо парсить, в нем быстрее ищутся элементы.
> Профит в том, что этот XML можно вывести в чистом виде для "'экспресс-дебага"
echo $xml_data, var_dump($array) — занимает ожинаково места, но 2й вариант в разы читабельнее (у меня рсширение Xdebug раскрашивает вывод var_dump())
> или предоставления примитивного API
echo Array2XML($array) — это сложно?
> можно одним шаблоном преобразовать в HTML, другим в XHTML, третьим — в RSS, четвертым в ATOM, пятым в PDF, шестым в SVG
А php-массив можно еще и в JSON преобразовать одной функцией (json_encode() вроде), а XML? А в указанные вами форматы можно преобразовать массив и обычнм шаблонизатором, и работать будет быстрей.
> Плюс этот XML удобно кешировать (причем по-кусочкам)
Мда, скажу по секрету, элементы массива сериализовать в кеш тоже недолго)
На стороне XML — всякие гиганты, типа Sun с явой и майкрософт. но мне, как человеку пишущему код. в этом мусоре копаться неохота и пальцы отбивать, наюирая тонну скобок и лишних слов. А так как на с Sun, ни с МС я не связан. то и следовать их дурацким стандартам я не буду ))
Кстати, XML достал и других разработчиков, например в symfony используется YAML, в отличие от XML он легко читается и пишется человеком (а не роботами из отдела раpработки майкрософт, которые проталкивают свой XML).
> Профит в том, что этот XML можно вывести в чистом виде для "'экспресс-дебага"
echo $xml_data, var_dump($array) — занимает ожинаково места, но 2й вариант в разы читабельнее (у меня рсширение Xdebug раскрашивает вывод var_dump())
> или предоставления примитивного API
echo Array2XML($array) — это сложно?
> можно одним шаблоном преобразовать в HTML, другим в XHTML, третьим — в RSS, четвертым в ATOM, пятым в PDF, шестым в SVG
А php-массив можно еще и в JSON преобразовать одной функцией (json_encode() вроде), а XML? А в указанные вами форматы можно преобразовать массив и обычнм шаблонизатором, и работать будет быстрей.
> Плюс этот XML удобно кешировать (причем по-кусочкам)
Мда, скажу по секрету, элементы массива сериализовать в кеш тоже недолго)
На стороне XML — всякие гиганты, типа Sun с явой и майкрософт. но мне, как человеку пишущему код. в этом мусоре копаться неохота и пальцы отбивать, наюирая тонну скобок и лишних слов. А так как на с Sun, ни с МС я не связан. то и следовать их дурацким стандартам я не буду ))
Кстати, XML достал и других разработчиков, например в symfony используется YAML, в отличие от XML он легко читается и пишется человеком (а не роботами из отдела раpработки майкрософт, которые проталкивают свой XML).
Кстати, XSL очень люблю, но пока были основные проблемы в удобном интерфейсе для преобразования php переменных в XML… DOM слишком навороченный… Делать нативный PHP массив преобразуемый рекурсивно — начинаешь путаться в массиве в этом… Возникает желание для манипулирования им сделать интерфейс какой-то — снова приходишь к подобию DOM.
Какой тут подход наиболее разумный посоветуете??
Какой тут подход наиболее разумный посоветуете??
1. Можно совместить полезное с приятным, и формировать данные через SimpleXml.
2. Хелперы можно и напрямую из XSLT использовать, через php:function()
2. Хелперы можно и напрямую из XSLT использовать, через php:function()
1) Лишние, неискоренямые тормоза получаются. Имеем: данные зачем-то преобразуются в Xml, который потом все равно еще раз преобразется.
Кстати, дерево DOM (с кучей тегов, аттрибутов, ссылок на родительские/ соседние элементы) тяжелее простого php-массива, и даже в бинарном расширении будет работать медленно, так ведь? А поиск элемента по индексу всяко быстрее поиска по Xpath (который может содержать сложные выражения к слову), эти тормоза невозмлжно оптимизировать никак.
2) Ну вот, давайте еще 30 слоев добавим. Почему бы сразу в php-код не компилировать?
3) Короткие теги — плохо, не помню почему :) Конструкция не содержит эскейпинга html entities — а значит, никуда не годится.
Удобнее всего Смарти-подобный синтаксис, с тегами, модификаторами (как у вас с этим в XML ?))) и наследованием.
Кстати, еще есть проблема локализации шаблонов.
> Я сам Смарти не очень люблю.
А я не люблю все существующие шаблонизаторы, у них у всех недостатки ((
Кстати, дерево DOM (с кучей тегов, аттрибутов, ссылок на родительские/ соседние элементы) тяжелее простого php-массива, и даже в бинарном расширении будет работать медленно, так ведь? А поиск элемента по индексу всяко быстрее поиска по Xpath (который может содержать сложные выражения к слову), эти тормоза невозмлжно оптимизировать никак.
2) Ну вот, давайте еще 30 слоев добавим. Почему бы сразу в php-код не компилировать?
3) Короткие теги — плохо, не помню почему :) Конструкция не содержит эскейпинга html entities — а значит, никуда не годится.
Удобнее всего Смарти-подобный синтаксис, с тегами, модификаторами (как у вас с этим в XML ?))) и наследованием.
Кстати, еще есть проблема локализации шаблонов.
> Я сам Смарти не очень люблю.
А я не люблю все существующие шаблонизаторы, у них у всех недостатки ((
о! Хорошо что про локализацию шаблонов напомнили!
В XSLT это делается вообще шоколадно!
<xsl:variable name=«transl» select=«document( concat('translations/',$lang_,'.xml') )» />
Т.е. для разных языков создаются разные файлы $lang_.xml (см www.starcraft2.com/strings/ru_ru/strings.xml ) и непосредственно в XSL автоматически подключается нужный в зависимости от входных данных. Потом для вывода текста делаем
<xsl:value-of select="$trans/str[@id='something']"/> (см www.starcraft2.com/layout/frontpage.xsl )
Кстати, по поводу XSLT на клиенте тоже на сайте старкрафта www.starcraft2.com/ поглядите исходные коды страницы — он в зависимости от юзерагента выдает либо XSL-ки и XML либо преобразованный на сервере HTML если браузер XSL не понимает
В XSLT это делается вообще шоколадно!
<xsl:variable name=«transl» select=«document( concat('translations/',$lang_,'.xml') )» />
Т.е. для разных языков создаются разные файлы $lang_.xml (см www.starcraft2.com/strings/ru_ru/strings.xml ) и непосредственно в XSL автоматически подключается нужный в зависимости от входных данных. Потом для вывода текста делаем
<xsl:value-of select="$trans/str[@id='something']"/> (см www.starcraft2.com/layout/frontpage.xsl )
Кстати, по поводу XSLT на клиенте тоже на сайте старкрафта www.starcraft2.com/ поглядите исходные коды страницы — он в зависимости от юзерагента выдает либо XSL-ки и XML либо преобразованный на сервере HTML если браузер XSL не понимает
Шоколадно?
То же самое, например, в Django выглядит так:
То же самое, например, в Django выглядит так:
{% trans "something" %}
О! Наконец-то мне дали пример XSLT-шаблона! По моему, в нормальном шаблонизаторе как минимум будет меньше букв:
> param=«concat($loc/strs/str[@id='sc2.mediahost'],'/flash/global/')»
В нормальном шаблонизаторе: param="{$varname.sc2.mediahost}/flash/global"
> xsl:value-of select="$loc/strs/str[@id='sc2.featured.link.1']"/
{$varname.sc2.feutured.link[1]|escape:html}
Ну разве не проще? А ведь оно еще и работать быстрее будет (найти элемент в масиве проще, чем в DOM-дереве по XPath).
Перевод мог бы выглядеть примерно так (мог бы, потому что я еще не написал свой шаблонизатор :) ):
{_ «Phrase in English» }
А строки берутся из файла .po (созданного с помощью gettext()). Использование gettext лучше имхо тем, что он быстрее (так как там спец. бинарный формат с массивом key => value для поиска перевода, кроме того, файл переводов при использовании Апача и PHP кешируется в памяти, и его не надо каждый раз грузить с диска), кроме того для редактирования файлов переводов есть свободное ПО с GUI (например, POEdit), а у вас надо ручками править XML ((
> param=«concat($loc/strs/str[@id='sc2.mediahost'],'/flash/global/')»
В нормальном шаблонизаторе: param="{$varname.sc2.mediahost}/flash/global"
> xsl:value-of select="$loc/strs/str[@id='sc2.featured.link.1']"/
{$varname.sc2.feutured.link[1]|escape:html}
Ну разве не проще? А ведь оно еще и работать быстрее будет (найти элемент в масиве проще, чем в DOM-дереве по XPath).
Перевод мог бы выглядеть примерно так (мог бы, потому что я еще не написал свой шаблонизатор :) ):
{_ «Phrase in English» }
А строки берутся из файла .po (созданного с помощью gettext()). Использование gettext лучше имхо тем, что он быстрее (так как там спец. бинарный формат с массивом key => value для поиска перевода, кроме того, файл переводов при использовании Апача и PHP кешируется в памяти, и его не надо каждый раз грузить с диска), кроме того для редактирования файлов переводов есть свободное ПО с GUI (например, POEdit), а у вас надо ручками править XML ((
> Конструкция не содержит эскейпинга html entities — а значит, никуда не годится
Кажется, имеет место недопонимание. В XSLT по умолчанию как раз включен квотинг — просто по определению (в том и сила). А чтобы его выключить при каком-то единичном выводе, нужно писать длинное <xsl:value-of select=«val» disable-output-escaping=«yes» />. Конструкция же {val} вне тэгов в ShortXSLT просто заменяется на <xsl:value-of select=«val» />, который как раз КВОТИТ данные.
Кажется, имеет место недопонимание. В XSLT по умолчанию как раз включен квотинг — просто по определению (в том и сила). А чтобы его выключить при каком-то единичном выводе, нужно писать длинное <xsl:value-of select=«val» disable-output-escaping=«yes» />. Конструкция же {val} вне тэгов в ShortXSLT просто заменяется на <xsl:value-of select=«val» />, который как раз КВОТИТ данные.
Ок, тут я ошибся. Когда напишу свой php-шаблонизатор, тоже сделаю автоквотинг :) И все же эти «xsl:value-of select=» — длинновато, ну не для человека этот формат, что бы там не говорили.
Добавлю, что квотинг нельзя отключить в атрибутах. А то это не всегда очевидно для начинающих…
Давайте не будем начинать срач по поводу XSLT, этой теме посвящено и так уже слишком много.
Нафиг нафиг, посидел тут с поделием explay, больше жедания нет
А я за PHPTemplate, который в Drupal'е активно юзается
вначале было слово… угу. на том и остановимся. кесарю — кесарево. не грузите людей (которые рисуют, гуят, и развивают свое воображение) наследованием, виртуальными функциями, и )))))))
Для них должен быть ИНСТРУМЕНТ. Но язык, на котором программер пишет, имеет к этому языку весьма посредственное отношение. Восприятие другое, хоть об стенку убейся.
Суммари: пока инструмента нет, будут шаблоны.
Для них должен быть ИНСТРУМЕНТ. Но язык, на котором программер пишет, имеет к этому языку весьма посредственное отношение. Восприятие другое, хоть об стенку убейся.
Суммари: пока инструмента нет, будут шаблоны.
Впишите в сравнение Quicky и возрадуйтесь ;-)
Quicky очень нравится. Пользуюсь им постоянно, но сейчас в процессе изучения Yii и честно скажу смотрю не в его сторону (не сторону Quicky).
Он чем-то лучше? Расскажите. Не могу определиться с шаблонизатором в новом проекте, пока отказался от Smarty, использую свой двадцатистрочный велосипед.
Во-первых, он просто очень развит, и писался не от балды, а в применении в реальным проектам. То есть функционал по мере необходимости дописывался. Например, там есть области видимости переменных, т.е. можно объявить {local $i = 0} и эта переменная будет доступна лишь в этом шаблоне, и не перепишет другие. Есть наследование шаблонов, inline-includes, и т.д. и т.п. Сложнее сказать чего там нет.
Во-вторых, он писался под HighLoad и там сделан акцент в первую очередь на производительность. Области видимости там не копируются, плагины линкуются статично, и т.д. и т.п.
Почитайте документацию, посмотрите примеры, сами всё поймете :-)
Во-вторых, он писался под HighLoad и там сделан акцент в первую очередь на производительность. Области видимости там не копируются, плагины линкуются статично, и т.д. и т.п.
Почитайте документацию, посмотрите примеры, сами всё поймете :-)
Ок, спасибо, посмотрю )
Ну ок, а можно прямо из коробки сделать что-то типа такого:
1) В шаблонизатор передается ссылка на объект $page,
2) В шаблоне встречается {$page.title|deferred}
3) А где-то ниже {action news/view/18}, вызывающее функцию, которая помимо вывода в шаблон, меняет значение глобальной переменной $page, которую мы предварительно передали по ссылке шаблонизатору, в результате чего в инструкции {$page.title|deferred}, которая выше по коду мы получим вывод уже измененной переменной.
?
Я конечно вижу то там постфильтры есть, которыми это можно реализовать и т. п., но вопрос в силе (приведенный мной синтаксис взят из головы, как это будет описано в шаблоне — не играет большого значения).
Я же так понимаю, Вы — разработчик этого шаблонизатора, значит много времени этот вопрос у вас не отнимет :)
1) В шаблонизатор передается ссылка на объект $page,
2) В шаблоне встречается {$page.title|deferred}
3) А где-то ниже {action news/view/18}, вызывающее функцию, которая помимо вывода в шаблон, меняет значение глобальной переменной $page, которую мы предварительно передали по ссылке шаблонизатору, в результате чего в инструкции {$page.title|deferred}, которая выше по коду мы получим вывод уже измененной переменной.
?
Я конечно вижу то там постфильтры есть, которыми это можно реализовать и т. п., но вопрос в силе (приведенный мной синтаксис взят из головы, как это будет описано в шаблоне — не играет большого значения).
Я же так понимаю, Вы — разработчик этого шаблонизатора, значит много времени этот вопрос у вас не отнимет :)
Неа, из коробки такого сделать нельзя. Можно конечно написать плагинчик deferred, который будет подставлять уникальную строку в output buffer, а потом искать и подменять в нужный момент. IMHO, это положит хрен на производительность. Не вижу оптимальных путей реализации для данного костыля.
Да, Мы разработчик.
Да, Мы разработчик.
А где у него документация?
В репе на гугле есть папке _doc.
Давайте сравним его в контексте перевода:
1. Наследование?
2. Песочница?
3. Автоматическое экранирование?
4. Синтаксис у него вроде вполне стандартны
Если я правильно увидел беглым взглядом то первые три пункта отсутствуют. Из чего вывод — сравнивая таким образом твиг не победишь :)
1. Наследование?
2. Песочница?
3. Автоматическое экранирование?
4. Синтаксис у него вроде вполне стандартны
Если я правильно увидел беглым взглядом то первые три пункта отсутствуют. Из чего вывод — сравнивая таким образом твиг не победишь :)
1. {extends} замечательно работает.
2. Что это? В плане защиты чего бы то ни было — это не нужно. В плане отделения областей видимости — это и так реализовано, достаточно запретить шаблону смотреть в global. Это легко.
3. Делаете auto_escape = true, и затем чтоб вывести html как есть надо сделать {$var|html}, иначе проэкранируется.
4. Более чем стандартный, расширенный синтаксис Quicky.
=) Как их можно сравнивать? В Quicky значительно больше фич, например shortcut'ы есть и компиляционные операторы. То есть можно программировать компиляцию шаблона (_if, _foreach, и т.д.).
2. Что это? В плане защиты чего бы то ни было — это не нужно. В плане отделения областей видимости — это и так реализовано, достаточно запретить шаблону смотреть в global. Это легко.
3. Делаете auto_escape = true, и затем чтоб вывести html как есть надо сделать {$var|html}, иначе проэкранируется.
4. Более чем стандартный, расширенный синтаксис Quicky.
=) Как их можно сравнивать? В Quicky значительно больше фич, например shortcut'ы есть и компиляционные операторы. То есть можно программировать компиляцию шаблона (_if, _foreach, и т.д.).
А чем ему <?= не угодил?
В случае когда короткие теги включены PHP будет интерпретировать xml вставки как свой код.
Что делают xml-вставки в PHP-коде?
Наоборот, php код в xml файле. Вообще за конструкцией <? может идти все что угодно, xml, php да мало ли что еще придумают в будущем. И обработка коротких тегов добавляет только проблемы.
Т.е. сознательный отказ от возможностей самого языка ради очередной прослойки, синтаксис которой снова должен учить верстак.
Я ещё понимаю, когда речь идёт про C-шные шаблонные движки для php. Но php на php для php?
Я ещё понимаю, когда речь идёт про C-шные шаблонные движки для php. Но php на php для php?
Отказ от <? в пользу <?php. Уже сейчас вы не можете вставить в шаблон xhtml строку
<?xml version=«1.0» encoding=«UTF-8» ?> предусмотренный стандартом.
Если у вас сейчас нет проблем с короткими тегами в шаблонах, вы не застрахованы что они у вас не появятся через год или два.
<?xml version=«1.0» encoding=«UTF-8» ?> предусмотренный стандартом.
Если у вас сейчас нет проблем с короткими тегами в шаблонах, вы не застрахованы что они у вас не появятся через год или два.
Я правильно понимаю, что в одном месте написать <?='<?'?>xml — действительно сложнее, чем всюду по коду писать <?php echo вместо <?=?
Чертовски верный аргумент. На уровне «Если вы живы в данный момент, то это ещё не означает, что через год или два так же будете живы».
Если у вас сейчас нет проблем с короткими тегами в шаблонах, вы не застрахованы что они у вас не появятся через год или два
Чертовски верный аргумент. На уровне «Если вы живы в данный момент, то это ещё не означает, что через год или два так же будете живы».
<?='<?'?>xml
Ну это ведь чертовски некрасивый костыль
Ну так любители echo и тут не остались обделёнными — они имеют возможность написать <? echo '<?xml version=«1.0» encoding=«UTF-8»?>'?>
А теперь ещё задумаемся о том, что значение кодировки будет являться точно таким же динамическим параметром, например.
То есть весь сыр-бор из-за вывода '?', причём наверняка это ещё и окажется всего в одном месте в каком-нить одном общем подключаемом шаблоне заголовка…
А теперь ещё задумаемся о том, что значение кодировки будет являться точно таким же динамическим параметром, например.
То есть весь сыр-бор из-за вывода '?', причём наверняка это ещё и окажется всего в одном месте в каком-нить одном общем подключаемом шаблоне заголовка…
> xml
Мда, единственная ассоциация с таким унылокодом — поговрка про мышей и кактус. Вы эту конструкцию у индийских коллег подчерпнули?
Мда, единственная ассоциация с таким унылокодом — поговрка про мышей и кактус. Вы эту конструкцию у индийских коллег подчерпнули?
> Наоборот, php код в xml файле.
XML строится по данным, как правило ;) Так что пример из области фантастики имхо )
XML строится по данным, как правило ;) Так что пример из области фантастики имхо )
И все же ответьте на вопрос. Что делают xml и php в одном файле?
пример — темплейт для рендеринга рсс
В php 5.3 он deprecated кстати если не ошибаюсь.
ru2.php.net/manual/en/migration53.deprecated.php чёт не видать?
не deprecated, просто отключен по умолчанию. можно включить
в 6-том даже планируют удалить поддержку коротких тегов
в 6-том даже планируют удалить поддержку коротких тегов
ИМХО смарти как одно из простых решений еще долго будет на рынке движков шаблонов. Он прост, сильно распространен и легко найти верстальщика знает его или который сумеет справиться со смарти.
Порой этот фактор критичней чем производительность или скажем экранирование. Просто скинут эти проблемы на программистов/админов, что-бы те или подкрутили производительность или плетки выдадут, для обучения верстальщиков "|escape".
Порой этот фактор критичней чем производительность или скажем экранирование. Просто скинут эти проблемы на программистов/админов, что-бы те или подкрутили производительность или плетки выдадут, для обучения верстальщиков "|escape".
Проблему шаблонизаторов давно уже забыл.
Когда сам делал проекты с нуля — да, использовал, но и то — ради красоты кода.
А теперь у нас есть верстальщик. Он вообще в PHP-код не заглядывает — дал нам свёрстанный макет, мы его сами внедряем в скрипты. Вот и все дела.
Когда сам делал проекты с нуля — да, использовал, но и то — ради красоты кода.
А теперь у нас есть верстальщик. Он вообще в PHP-код не заглядывает — дал нам свёрстанный макет, мы его сами внедряем в скрипты. Вот и все дела.
Объясните, почему вы сравниваете фреймворк на одном языке программирования с другим языком программирования без фреймворков?
> нет, использование более компактного <?= непреемлемо
Отчего же? Прямо так без обоснований?)
Отчего же? Прямо так без обоснований?)
Насколько я понял из лога выше, то причины не были придуманы(кроме неправильной работы с XML).
Но вместо отказа от <? можно просто работать с XML правильно. Это более верное решение проблемы ;)
Но вместо отказа от <? можно просто работать с XML правильно. Это более верное решение проблемы ;)
Что значит правильно?
'<?' — в XML стандартный префикс для инструкций обработки (Processing Instructions). Если в моем XML шаблоне содержатся такие инструкции и короткие теги PHP включены, то куда меня пошлет PHP (а потом и парсер XML)?
'<?' — в XML стандартный префикс для инструкций обработки (Processing Instructions). Если в моем XML шаблоне содержатся такие инструкции и короткие теги PHP включены, то куда меня пошлет PHP (а потом и парсер XML)?
Ну так выключите персонально для этого шаблона short_open_tag через ini_set… Верно ведь, что на типичном сайте XML-шаблонов значительно меньше, чем HTML-шаблонов?
Если сайт на xHTML, то неверно ;) (переписку выше в комментах про вывод <?xml… > видел, ну это так, придирка) Но проблема в том, что шаблоны часто пишет не разработчик, более того разработчик может и не знать среду выполнения, может там переопределение параметров вообще запрещено (встречался такой, что например, не давал включить вывод ошибок в браузер).
Всё же лучше я буду писать шаблоны так, как считаю нужным, будучи уверенным, что в любой представимой среде хоть тут ошибок не будет, чем буду описывать в доках для будущих верстальщиков такие нюансы, как вывод <?xml… ?> через echo, да еще лишняя строчка в системных требованиях с настройкой которую сами разработчики PHP не рекомендуют включать.
Всё же лучше я буду писать шаблоны так, как считаю нужным, будучи уверенным, что в любой представимой среде хоть тут ошибок не будет, чем буду описывать в доках для будущих верстальщиков такие нюансы, как вывод <?xml… ?> через echo, да еще лишняя строчка в системных требованиях с настройкой которую сами разработчики PHP не рекомендуют включать.
> Ну так выключите персонально для этого шаблона short_open_tag через ini_set…
Это вам индийские коллеги такое решение подсказали?
Кстати, по поводу того, что мол долго писать [?php echo — у меня вбито несколько сокращений в редактор, например [угловая скобка] [e] [Ctrl +B] — как раз всятавляет конструкцию [? php echo; ?], и код выглядит нормально, и печатать недолго.
Это вам индийские коллеги такое решение подсказали?
Кстати, по поводу того, что мол долго писать [?php echo — у меня вбито несколько сокращений в редактор, например [угловая скобка] [e] [Ctrl +B] — как раз всятавляет конструкцию [? php echo; ?], и код выглядит нормально, и печатать недолго.
на некоторых хостингах сокращенная версия отключена.
нужно писать <?php=
нужно писать <?php=
статья обсуждалась в LJ — community.livejournal.com/ru_php/1426579.html
>необходимо отобразить массив и вывести текст по умолчанию, если этот массив пуст
А почему нельзя вывести массив через print_r? Навскидку, имхо читабильнее:
По мне, так можно обойтись и вовсе одним print_r зачастую.
А почему нельзя вывести массив через print_r? Навскидку, имхо читабильнее:
<?php
$a = array ('a' => 'apple', 'b' => 'banana', 'c' => array ('x', 'y', 'z'));
if (print_r (@$a, true))
{
print_r($a);
}
else
{
echo "No values";
}
?>
* This source code was highlighted with Source Code Highlighter.По мне, так можно обойтись и вовсе одним print_r зачастую.
Автор Симфони открыл для себя Джангу, эврика! :-) Почему бы тогда просто не писать на Джанге? ИМХО она лучше, чем конкретно Симфони — по крайней мере, в Джанге некривая ОО-модель, а также весьма элегантный ORM (хотя в Симфони Doctrine внедрять, я с ним не работал, а вот с Propel — пришлось и много). Если бы у меня был выбор только между Симфони и Джангой, а бы выбрал последнюю — даже учитывая всю мою любовь к PHP…
Ну глядишь увидим в следующем релизе Симфони еще и влияние Джанги, как сейчас видно влияние Рельс ;) Что плохого?
НЛО прилетело и опубликовало эту надпись здесь
Sensio о Django знает давно) Другое дело что там не нашлось чего внедрят, т.е. такого революционного как с рельсами но поводу Symfony 2 уже не будет inspired by RoR, исходники буквально неделю назад выложил Фабьен, теперь это будет нечто похожее на набор компонентов как ZF, но с CLI.
Что касается ORM, то propel действительно очень уступает доктрине, во-первых с его criteria, и не явную работу с сложными джойнами, во-вторых доктрина это действительно похоже на ORM с таких яп как java.
Что касается ORM, то propel действительно очень уступает доктрине, во-первых с его criteria, и не явную работу с сложными джойнами, во-вторых доктрина это действительно похоже на ORM с таких яп как java.
Опять велик.
Ну сделайте класс своего api и используйте прелести php.
Выгода?
Сократит код, тот кто не хочет «рыться» и изучать api проекта, может «по быстрому» использовать… чистый php (будем считать по умолчанию гораздо распространенным шаблонизатором :). Да пора забыть про шаблонизаторы. API имхо, api.
А шаблонизаторами не всегда можно свободно «оперировать» и всё описать, все же php&api гораздо гибче.
Ну сделайте класс своего api и используйте прелести php.
Выгода?
Сократит код, тот кто не хочет «рыться» и изучать api проекта, может «по быстрому» использовать… чистый php (будем считать по умолчанию гораздо распространенным шаблонизатором :). Да пора забыть про шаблонизаторы. API имхо, api.
А шаблонизаторами не всегда можно свободно «оперировать» и всё описать, все же php&api гораздо гибче.
Постоянно слышу, как люди хвалят шаблонизаторы и даже пишут что-то свое, но я все никак не могу их понять. %)
Почему «использование более компактного
Почему «использование более компактного
Dwoo — тоже дурной, состоит из кучи файлов, у меня не раз бывало, что в нем блоьше файлов чем в остальных компонентах сатйа.
Жаль, что нет сравнения скорости с шаблоном на чистом PHP.
А смысл, если автор считает его невзможным в исользовании?
Если интересно, есть перевод подведения итогов habrahabr.ru/blogs/php/76021/
Эти отговорки про «длинность» и «громоздкость» конструкций просто уже клише какоето для оправдывания существования шаблонизаторов.
Автор Twig — лох, потому-что писать шаблонизатор из-за незнания возможностей php и своих эстетических предпочтений будет только лошара.
Автор говорит про простоту шаблонизатора — на самом же деле предоставляет еще один шаблонизатор (да еще и на php) со своими фичами и граблями, большинство из которых не будет использоватся за ненужностью.
Автор Twig — лох, потому-что писать шаблонизатор из-за незнания возможностей php и своих эстетических предпочтений будет только лошара.
Автор говорит про простоту шаблонизатора — на самом же деле предоставляет еще один шаблонизатор (да еще и на php) со своими фичами и граблями, большинство из которых не будет использоватся за ненужностью.
Кто же разряды разделет запятыми? Если переводите — замените их на пробелы.
Я долго пытался понять почему Twig генерит всего три с половиной шаблона в секунду и при этом является самым быстрым.
Я долго пытался понять почему Twig генерит всего три с половиной шаблона в секунду и при этом является самым быстрым.
меня мой шаблонизатор совершенно устраивает, использовал его довольно объемных проектах, возникли только некоторые желательные улучшения, которые я добавлю в ближайшем будущем
примерно сейчас это выглядит так:
а хочу:
(то есть добавить чуточку xslt))
примерно сейчас это выглядит так:
{foreach name=page source=#sctucture}
{if #page.isHide=='0'}
<li>{#page.name}</li>
{/if}
{/foreach}а хочу:
{foreach name=page source=#sctucture/isHide=='0'}
<li>{#page.name}</li>
{/foreach}(то есть добавить чуточку xslt))
честно скажу, мало проводил исследований других шаблонизаторов, просто сделал как бы мне было удобно. хотя работал с xslt больше двух лет и очень остался доволен. но объемный код xslt расстраивал конечно и усложнял работу с сложными проектами, особенно под конец рабочего дня, когда глаза не могу найти в коде то, что нужно))
Плотно пощупал тут Twig. Неплох по скорости, синтаксис по умолчанию более удобный, чем у Smarty. Но убило напрочь то, что так и не понял как без правки самого Twig'а, как вводить именованные параметры в тэгах. Т.е., скажем,
{% module name=«my_module» id=$id %}
Варианты, типа
{% module name as «my_module» id as id %}
смотрятся чудовищно.
Если бы не это, попробовал бы Twig в качестве шаблонизатора в новых классах своего фреймворка.
Захотел также, для сравнения, оценить Quicky, но с удивлением обнаружил, что релиз не обновлялся с весны. Тогда это было очень сыро и недоработано. Проект скорее мёртв, чем жив?
…
Похоже, пока по-прежнему будут сидеть на Smarty :)
{% module name=«my_module» id=$id %}
Варианты, типа
{% module name as «my_module» id as id %}
смотрятся чудовищно.
Если бы не это, попробовал бы Twig в качестве шаблонизатора в новых классах своего фреймворка.
Захотел также, для сравнения, оценить Quicky, но с удивлением обнаружил, что релиз не обновлялся с весны. Тогда это было очень сыро и недоработано. Проект скорее мёртв, чем жив?
…
Похоже, пока по-прежнему будут сидеть на Smarty :)
Что за фреймворк? :)
Как обычно, свой собственный :) — bors.balancer.ru/
…
А по теме передачи параметров, без хака Twig'а родил конструкции вида:
{% module name:«my_module» id:this.id %}
Но, вообще, повозиться для полной поддержки Twig'а много придётся. Тэги, фильтры, блоки…
…
А по теме передачи параметров, без хака Twig'а родил конструкции вида:
{% module name:«my_module» id:this.id %}
Но, вообще, повозиться для полной поддержки Twig'а много придётся. Тэги, фильтры, блоки…
Я в своих проектах использую Quicky. Очень нравится.
я замерил этот ваш твиг с шаблоном чуть по сложнее чем «привет мир». в результате он только компилирует быстрее смарти3, а исполняется дольше.
исполнение в 3 раза медленнее хслт, который в 3 раза медленнее лапши на пхп. оно и не удивительно, там столько классов интерпретатору разгребать приходится… на каждый чих по классу.
исполнение в 3 раза медленнее хслт, который в 3 раза медленнее лапши на пхп. оно и не удивительно, там столько классов интерпретатору разгребать приходится… на каждый чих по классу.
А кто-нибудь уже использовал Twig на больших и нагруженных проектах или слышал об использовании в той или иной компании/проекте?
Можете указать конкретные проекты, нагрузки, размеры команд, сложности, с которыми столкнулись?
Проект начинался на Twig или переходили с чего-то?
Как разработчики справляются с обучением?
Занимаются ли верстальщики написанием/правкой шаблонов или только программеры?
Серьезные ли проблемы дает отсутствие обратной совместимости, например между версиями 0.9.6 и 0.9.9?
Знает ли кто, предполагается ли обратная совместимость в следующих версиях?
Можете указать конкретные проекты, нагрузки, размеры команд, сложности, с которыми столкнулись?
Проект начинался на Twig или переходили с чего-то?
Как разработчики справляются с обучением?
Занимаются ли верстальщики написанием/правкой шаблонов или только программеры?
Серьезные ли проблемы дает отсутствие обратной совместимости, например между версиями 0.9.6 и 0.9.9?
Знает ли кто, предполагается ли обратная совместимость в следующих версиях?
нет, использование более компактного
<?=непреемлемо
???????????????????????????????
после такого "аргумента" статью можно дальше в принципе и не читать )
Перевод: Шаблонизаторы в PHP