Комментарии 88
Один вопрос — зачем?
Есть же шаблонизаторы, чтобы не мешать код и верстку. А тут верстка остается все равно в коде.
Задача не ставилась облегчить работу верстальщику, а только облегчить жизнь тому, кто вынужден в php вставлять html.
так шаблонизаторы и убирают этот «костыль», когда впаивают в код верстку, чтобы так не делали.
Это походу просто этап такой.
1) начал кодить — код+ html в одном файле
2) уже делишь код на несколько php файлов, освоил include, но верстка все равно вперемешку
3) начал понимать что что то как то не очень — решил «генерировать» html в ходе кода
4) гордишься своей гениальностью и хочешь со всеми поделиться
5) понимаешь, что все равно херь какаято
6) начинаешь понимать, что надо разделять не просто по php файлам, а еще по сильнее — отделять верстку
7) недолго гугля находишь — шаблонизаторы
8) пытаешься освоить какойнибудь легковестный шаблонизатор
9) освоил — понял, что много кода тянет лишнего — в просто шаблонизаторе овер кода, чем ты написал на проект
10) написал свой шаблонизатор в 100 строк!
11) гордишься своей гениальностью и хочешь со всеми поделиться
12)начинает не хватать функциональности и гибкости — городишь костыли в коде и расширяешь функционал своего шаблонизатора, чтобы всё же используя возможность своего шаблонизатора все же не сорваться и не воткнуть кусок верстки
13)Шаблонизатор уже подошел к 1к строк кода, и все равно всплывает, что не хватает возможностей.
14)Успокоился пришел в %ПОПУЛЯРНЫЙ_ШАБЛОНИЗАТОР%
1) начал кодить — код+ html в одном файле
2) уже делишь код на несколько php файлов, освоил include, но верстка все равно вперемешку
3) начал понимать что что то как то не очень — решил «генерировать» html в ходе кода
4) гордишься своей гениальностью и хочешь со всеми поделиться
5) понимаешь, что все равно херь какаято
6) начинаешь понимать, что надо разделять не просто по php файлам, а еще по сильнее — отделять верстку
7) недолго гугля находишь — шаблонизаторы
8) пытаешься освоить какойнибудь легковестный шаблонизатор
9) освоил — понял, что много кода тянет лишнего — в просто шаблонизаторе овер кода, чем ты написал на проект
10) написал свой шаблонизатор в 100 строк!
11) гордишься своей гениальностью и хочешь со всеми поделиться
12)начинает не хватать функциональности и гибкости — городишь костыли в коде и расширяешь функционал своего шаблонизатора, чтобы всё же используя возможность своего шаблонизатора все же не сорваться и не воткнуть кусок верстки
13)Шаблонизатор уже подошел к 1к строк кода, и все равно всплывает, что не хватает возможностей.
14)Успокоился пришел в %ПОПУЛЯРНЫЙ_ШАБЛОНИЗАТОР%
15) Написал об этом коментарий на хабрахабре
конечно, ведь
продолжу:
16) возвращаешься к идее использования php как шаблонизатора, просто вынося шаблоны в отдельный файл.
хочешь со всеми поделиться
продолжу:
16) возвращаешься к идее использования php как шаблонизатора, просто вынося шаблоны в отдельный файл.
if($element instanceof CFormInputElement)
{
if($element->type==='hidden')
return "<div style=\"visibility:hidden\">\n".$element->render()."</div>\n";
else
return "<div class=\"row field_{$element->name}\">\n".$element->render()."</div>\n";
}
Код из Yii, скажите, а они на каком сейчас этапе?
на этапе
∞ надо переписать
подход собрать гору данных и скормить их шаблонизатору для отрисовки в разы проще — не надо в ходе кода городить и подстраиваться под отрисовку.
∞ надо переписать
подход собрать гору данных и скормить их шаблонизатору для отрисовки в разы проще — не надо в ходе кода городить и подстраиваться под отрисовку.
То есть вы против html кода в php в любом случае? Ну это ваша позиция, я считаю что он допустим для отрисовки стандартных интерфейсов, например того же bootstrap. И есть куча решений, где html код вшит в php.
php и создан чтобы отдавать html. Но логику от отрисовки лучше отделять, чтобы в будущем не мучиться если надо перенести кудато код.
я согласен, но у меня отрисовку можно будет менять только через расширение классов, так изначально задумывалось. Я пишу компоненты, через которые будут использоваться при написании сайта, а не сам сайт и его вьюшки с дизайном.
Но вот это
всёж верстка, если кому-то понадобиться после допилить сайт и где то что то передвинуть или дорисовать атрибут, он полезет в ядро, менять там. В будущем, когда надо будет обновить движок, то апдейт сломает, то что поправили. Поэтому и рисуют элементы и мелкие части используя шаблоны — просто отправил туда массив переменных, и оно само наложило это всё и отрисовало. И это никак не влияет на обновления + скины.
CHtml::create()
->table()
->thead()
->tr()
->each($columns)
->th()
->text(function($column){
return $column['label'];
})
->end()
->endEach()
->end()
->end()
всёж верстка, если кому-то понадобиться после допилить сайт и где то что то передвинуть или дорисовать атрибут, он полезет в ядро, менять там. В будущем, когда надо будет обновить движок, то апдейт сломает, то что поправили. Поэтому и рисуют элементы и мелкие части используя шаблоны — просто отправил туда массив переменных, и оно само наложило это всё и отрисовало. И это никак не влияет на обновления + скины.
8) пытаешься освоить какойнибудь легковестный шаблонизатор
PHP достаточно легковесный шаблонизатор? )
4й шаг уже давно пройден, автор даёт ссылку на гитхаб, где у него уже целый фреймворк собственный
Оггосподи.
С ужасом понимаю что PHP постам только минусы ставить, увы.
С ужасом понимаю что PHP постам только минусы ставить, увы.
А где защита от XSS?
Сделаю картинкой, чтобы было видно все сразу:
Скрытый текст
Скажите, что я тут должен увидеть?
— меньше строк
— разная подсветка для html и php кода
— подсветка открывающего и закрывающего тега
— возможность свернуть содержимое тега
— разная подсветка для html и php кода
— подсветка открывающего и закрывающего тега
— возможность свернуть содержимое тега
а теперь представьте что этот код у вас где-то в классе, и этот html надо возвращать чтобы отправить письмо.
$template = new Template('mail.tpl');
$mail = new Mail;
$mail->setBody($template->render($data));
$mail->send();
а файл у вас прям рядом лежит? и так с каждым классом надо будет думать куда файл положить да?
Лично у меня шаблоны писем складируются в каталог mails.
Это не столь сложная задача чтоб о ней думать )
и так с каждым классом надо будет думать куда файл положить да?
Это не столь сложная задача чтоб о ней думать )
Ну, мне это не подходит. Мне нужно писать компоненты, в которых html внутри не изменится. Может если бы у меня была просто отправка писем, я бы не стал заморачиваться и сделал как вы.
Ну шаблонизатор можно использовать без шаблонизации:
или вы о чем?
Народ возмущается тому, что вы предлагаете писать:
Вместо:
Второй вариант может и длинее, но привычнее.
$template = new Template('mail.tpl');
$mail = new Mail;
$mail->setBody($template->render([]));
$mail->send();
или вы о чем?
Народ возмущается тому, что вы предлагаете писать:
$html->head()->title('Hello');
Вместо:
<html>
<head>
<title>Hello</title>
Второй вариант может и длинее, но привычнее.
Я так не предлагаю писать, боже упаси!
Этот класс я буду использовать только внутри других классов — компонентов, где заранее известно какие теги и классы будут.
Главная цель — избавить классы от html. Другие цели не ставились. Да, можно выносить html в файлы, но у меня html практически статичный, мне легче создать его каким-то объектом.
Этот класс я буду использовать только внутри других классов — компонентов, где заранее известно какие теги и классы будут.
Главная цель — избавить классы от html. Другие цели не ставились. Да, можно выносить html в файлы, но у меня html практически статичный, мне легче создать его каким-то объектом.
Намного приятнее смотрится, если использовать if/endif, foreach/endforeach и и прочее вместо фигурных скобок в HTML.
Для Вас расширяемость ограничивается extend'ом?
и…
шта?
и…
->option('array("value" => $data->value)')
->text('$data->text')
шта?
картинка_про_тролейбус_из_хлеба.bmp
Я считаю, что генерация HTML при помощи DOM-подобных приемов это очень правильный подход, и автор пытается это сделать.
Но получается криво.
Но получается криво.
Вы про DOMDocument?
А вообще это haml. Или jade.
Чем это пилить — пофиксите пару багов в парсере того или другого для php.
Чем это пилить — пофиксите пару багов в парсере того или другого для php.
Да я в курсе про haml, писал на нем в Ruby on Rails. Но хотелось написать свое, и написал.
ну так раз: packagist.org/search/?q=haml
и два — там надо было писать хамл, а не чудо спагететвое и называть его революционным способом регенации html из php )
и два — там надо было писать хамл, а не чудо спагететвое и называть его революционным способом регенации html из php )
Практически полностью отказались от компонентов CHtml. Один кастомный CGridView сжирает на 7мб памяти больше, чем нативные foreach. Сейчас php дорос до удобной шаблонизации без дополнительных надстроек, и не стоит бояться шорт-тэгов:
<?php foreach($myArr as $id =>$obj): ?>
<?php if ($obj->isShow): ?>
<?=$var; ?>
<?php endif; ?>
<?php endforeach; ?>
<?php foreach($myArr as $id =>$obj): ?>
<?php if ($obj->isShow): ?>
<?=$var; ?>
<?php endif; ?>
<?php endforeach; ?>
Спасибо, буду иметь ввиду
Можно легко заменить <?php на <? с помощью директивы short_open_tag, если вы не планируете пользовать PHP шаблонизацией в XML.
В некоторых проектах использование такой формы еще является стандартом. О шорт тэгах я кстати и написал.
что не соответствует psr-1 и добавляет проблем сторонним пользователям.
Когда вы пишете готовый сервис, у вас в компании могут быть свои стандарты, которые (возможно) отличаются от psr-1, и это вполне нормально.
конечно же, но это не повод советовать их использовать на хабре.
Почему же не повод? Psr-1 это не обязательство, а всего лишь стандарт. Я его не соблюдаю и имею право советовать это другим программистам.
а советовать надо best practices. а это следование рекомендованным стандартам. рекомендуя свои внутренние корпоративные стандарты без аргументации, вы плодите зло на Земле в виде например фреймворка автора.
Все современные популярные библиотеки следуют psr-1,2,4. Это удобно, единообразно, и не заставляет разработчика привыкать к новому для себя кодстайлу.
Стандарт в области кодстайла удобен не тем, что он лучше (многие моменты могут породить холивар вкусовщины), а тем, что он стандарт.
Все современные популярные библиотеки следуют psr-1,2,4. Это удобно, единообразно, и не заставляет разработчика привыкать к новому для себя кодстайлу.
Стандарт в области кодстайла удобен не тем, что он лучше (многие моменты могут породить холивар вкусовщины), а тем, что он стандарт.
а советовать надо best practices. а это следование рекомендованным стандартам.
А если я не согласен со стандартом, то мне надо вздохнуть и все равно рекомендовать стандарт?
Тут в комментах много советов автору. Комментирующие видимо хотят подтолкнуть его на путь истинный. Что хотите вы, я не в курсе.
Мое мнение таково: есть два варианта — либо вы советуете стандарт ибо он де-факто выигрышен тем, что стандарт, либо в случае несогласия со стандартом, предлагаете свой вариант, обосновывая почему ваш вариант лучше, ведь возможно вы и правы. Если вы считаете, что ваш, третий вариант — рекомендовать без аргументации — правилен, то обсуждение можно закрыть — я неавторитетен вас учить поведению на отраслевых ресурсах.
Мое мнение таково: есть два варианта — либо вы советуете стандарт ибо он де-факто выигрышен тем, что стандарт, либо в случае несогласия со стандартом, предлагаете свой вариант, обосновывая почему ваш вариант лучше, ведь возможно вы и правы. Если вы считаете, что ваш, третий вариант — рекомендовать без аргументации — правилен, то обсуждение можно закрыть — я неавторитетен вас учить поведению на отраслевых ресурсах.
Тут в комментах много советов автору. Комментирующие видимо хотят подтолкнуть его на путь истинный. Что хотите вы, я не в курсе
Я автору не советов не следовать psr-1. Вы что то путаете.
Мое мнение таково
Вы хотите чтоб я продемонстрировал используемый мной стандарт да еще и сравнил его с psr в комментариях? )
неиспользование шорт-тегов — один из пунктов psr-1.
Прочтите нашу ветку еще раз — не надо еще одной итерации с начала.
Прочтите нашу ветку еще раз — не надо еще одной итерации с начала.
неиспользование шорт-тегов — один из пунктов psr-1
Я разве спорю?
Прочтите нашу ветку еще раз — не надо еще одной итерации с начала
Не наблюдаю моего отступления от моего мнения, как и ваших аргументов.
вы не спорите, что это стандарт, но упоминаете, что можно юзать их, отключив директиву в php.ini. Это вредный совет, поскольку это пассивная рекомендация писать нестандартизированный код. Тот же автор увидит ваш комментарий и подумает: а действительно, зачем не везде <?php, ведь <? короче и компактнее. Не всем очевидно, что это вредно.
Это вредный совет, поскольку это пассивная рекомендация писать нестандартизированный код
Видимо кроме PSR вы другие стандарты не воспринимаете )
Тот же автор увидит ваш комментарий и подумает: а действительно, зачем не везде <?php, ведь <? короче и компактнее
И верно подумает.
Не всем очевидно, что это вредно
Даже мне не очевиден вред использования тегов.
есть принятый сообществом единый стандарт. Ключевое словосочетание «принятый сообществом». Это был прорыв, т.к. объединил все разрозненные кодстайлы, существовавшие до этого. Это значит, что все ведущие, все современные библиотеки используют один кодстайл. Вам очевидна выгода использование единого кодстайла? Очевидна выгода единого стандарта?
Подумает верно, ведь действительно шорт-теги короче и компактнее (хотя не дает никакого профита при разработке), но не полезнее.
Вред простой: а) для использования шорт-тегов нужно включать дополнительную директиву — не всегда возможно, б) библиотека с шорт-тегами не будет работать при настройках по умолчанию (а шорт-теги это все-таки не функциональная фича), в) тег <? неоднозначен (как вы упомянули выше)
С <?php проблем никаких нет, поэтому это стандартизированный тег.
Подумает верно, ведь действительно шорт-теги короче и компактнее (хотя не дает никакого профита при разработке), но не полезнее.
Вред простой: а) для использования шорт-тегов нужно включать дополнительную директиву — не всегда возможно, б) библиотека с шорт-тегами не будет работать при настройках по умолчанию (а шорт-теги это все-таки не функциональная фича), в) тег <? неоднозначен (как вы упомянули выше)
С <?php проблем никаких нет, поэтому это стандартизированный тег.
есть принятый сообществом единый стандарт
Да что вы привязались то ко всему стандарту в целом, я о частностях его говорю )
Вред простой: а) для использования шорт-тегов нужно включать дополнительную директиву — не всегда возможно, б) библиотека с шорт-тегами не будет работать при настройках по умолчанию (а шорт-теги это все-таки не функциональная фича), в) тег <? неоднозначен (как вы упомянули выше)
С <?php проблем никаких нет, поэтому это стандартизированный тег.
Меня всегда улыбало использование стандарта во вред разработки )
Я аргументировал все что можно — вы продолжаете оперировать абстракциями.
Я указал, что использование шорт-тега идет во вред разработке. Неиспользование во вред не идет.
Я указал, что использование шорт-тега идет во вред разработке. Неиспользование во вред не идет.
Ок, приведу пример. У меня компания, в ней работает десяток программистов. Код закрытый и распространять его мы не планируем. Все программисты сходятся во мнении, что писать <? ?> им проще чем <?php ?>. Хостится система на наших серверах и включить дериктиву мы можем. Мы пользуем PSR, но не пользуем некоторыми его частностями. Как думаете, мы все попадем в ад?
так с этого и началось: внутри своей компании используйте что хотите.
Аналогично: у нас продукт 4-летней давности, в легаси-коде используются шорт-теги, но все разработчики понимают ценность следованию стандартам и весь новый код пишут в psr-1,2,4.
Вы продолжаете юлить. Есть понимание, что следование стандартам важно?
Аналогично: у нас продукт 4-летней давности, в легаси-коде используются шорт-теги, но все разработчики понимают ценность следованию стандартам и весь новый код пишут в psr-1,2,4.
Вы продолжаете юлить. Есть понимание, что следование стандартам важно?
Предлагаю такой вариант шорт-тэгов:
<?php foreach($myArr as $id =>$obj) { ?>
<?php if ($obj->isShow) { ?>
<?=$var; ?>
<?php } ?>
<?php } ?>
<?php foreach($myArr as $id =>$obj) { ?>
<?php if ($obj->isShow) { ?>
<?=$var; ?>
<?php } ?>
<?php } ?>
на всякий случай напишу: у автора там на гитхабе целый фреймворк, который явно вдохновлен yii1 (год создания — 2008) и его стандартами тех лет. Поэтому автор не отделяет добро от зла и вряд ли внимает доводам из комментов.
Что за жесть :-(
Смешивать на одном логическом уровне разные сущности (в данном случае — имена элементов типа
tbody и действия типа each или render) — путь в никуда. Вот добавят в стандарт HTML элементы each или render, и приехали. ;-)
Мои глаза…
Обычный HTML вместо такого кода компактнее, проще и понятнее. Конструкции с тег()->end() выглядят отталкивающе. Было бы более элегантно, если бы оно было сделано как в jQuery.
верстальщик вернул хтмл, потом его полностью надо переписать на шаблонизаторе. затратно по времени, могут возникнуть проблемы с внесением изменений.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Генерация html на PHP