Comments 32
Хм… Мне вообще нравится синтаксис шаблонов такой:
Welcome!
{block: content}
В общем, сама идея — заключать логику в HTML комментарии (для указания начала/конца каких-то блоков, etc) и переменные в {}. Имхо это самый удобный вариант для верстальщика, который о PHP знает только по наслышке, зато профессионал в своем деле (HTML).
Welcome!
{block: content}
В общем, сама идея — заключать логику в HTML комментарии (для указания начала/конца каких-то блоков, etc) и переменные в {}. Имхо это самый удобный вариант для верстальщика, который о PHP знает только по наслышке, зато профессионал в своем деле (HTML).
Всё это очень уныло по сравнению с Wicket'ом.
=)) Хабрапарсер укротил мой пример, обрезав комментарии HTML :) Ну, в общем, можете посмотреть HTML-сорцы хабра. Идея — та же. Только имхо эти самые HTML комментарии шаблонизатором должны обрезаться.
нельзя ли кинуть ссылку на альтернативную семантику, не совсем понял, о чем речь:
Примечание: автор знаком с альтернативной семантикой HTML тега, избавляющего от атрибутов “for” и “id”. Но это здесь не важно. Когда мы избавились от них вместе со множеством других, в таком виде смотрится более компактно.
Примечание: автор знаком с альтернативной семантикой HTML тега, избавляющего от атрибутов “for” и “id”. Но это здесь не важно. Когда мы избавились от них вместе со множеством других, в таком виде смотрится более компактно.
pear quickform вам что-нить говорит? pear.php.net/manual/en/package.html.html-quickform.tutorial.php. Не правда ли очень похоже? Только построение форм отданно программисту, чтобы верстальшик ничего не сломал.
для любителей php native есть phpsavant.com/
для любителей php native есть phpsavant.com/
Ваш вариант это почти хелперы из Symfony, только хуже.
может проще будет описывать нужную форму через xml?
а за style — нужно руки отрывать. только class!
да и как( и кто) в вашем варианте будет описывать maxlength у текст-инпутов?
а за style — нужно руки отрывать. только class!
да и как( и кто) в вашем варианте будет описывать maxlength у текст-инпутов?
кстати о xml, как вы собираетесь написать
и еще
я правильно понимаю, что вы хотите воздействовать на следующую строку php кодом?
<?xml version="1.0" encoding="UTF-8"?>? php это <?php, а не <? к которому вы привыкли со времен первого денвера!и еще
<? form:: element('name', $name) ?>
<label>Name:</label> <input type=«text» style=«width:100px»>я правильно понимаю, что вы хотите воздействовать на следующую строку php кодом?
Забавно, что только после третьего своего комментария вы наконец стали догадываться, о чем речь в статье. Да, именно так. Но строчек там может быть не одна.
не переживайте, с пониманием у меня все хорошо.
зачем вы тогда мешаете код и верстку?
если уж хочется реализовать блочную модель обработки, то стоит обрабатывать формы так
зачем вы тогда мешаете код и верстку?
<? php form:: element('name', $name) ?>
<label>Name:</label> <input type=«text» style=«width:100px»>
<? php form:: element('test', $name) ?> <label>Test:</label>
<input type=«text» style=«width:100px»>
если уж хочется реализовать блочную модель обработки, то стоит обрабатывать формы так
<? php $form = new form();
$form->name = $name;
$form->test = $test;
$form->start(); //form:: start(array('name'=>$name))?>
<label>Name:</label> <input name=«name» type=«text» style=«width:100px»>
<label>Test:</label> <input name=«text» type=«text» style=«width:40px»>
<? php $form->stop();?>
В статье как раз рассказывается, как я попытался убрать из шаблона код и оставить только метки. Метки — неотъемлемая часть шаблона, даже если они сделаны в native PHP синтаксисе. Посмотрите, где вы видите код у меня? Только не формально, а содержательно. Как {var}, так и <?=$var?> это семантически не код, а метки. Так же как {block ...} и <? form:: element(...)?> не код, а метки блоков в разных синтаксисах. Вы же опять тяните одеяло назад именно к самому настоящему коду, на несколько строк, с присвоениями и т. д.
Даже если код вынесен в один блок, это делает шаблон еще менее удобным в работе. Теперь придется приводить в соответствие имя поля и переменной, которые отделены возможно десятками или сотнями строк друг от друга. Тот идентификатор, который можно было написать один раз, у вас надо повторить дважды. В таком случае лучше уж QuickForm.
Даже если код вынесен в один блок, это делает шаблон еще менее удобным в работе. Теперь придется приводить в соответствие имя поля и переменной, которые отделены возможно десятками или сотнями строк друг от друга. Тот идентификатор, который можно было написать один раз, у вас надо повторить дважды. В таком случае лучше уж QuickForm.
Давайте проследим за ходом мыслей:
>В статье как раз рассказывается, как я попытался убрать из шаблона код и оставить только метки.
те разделить логику и представление, замечательно
>Метки — неотъемлемая часть шаблона, даже если они сделаны в native PHP синтаксисе.
хорошо, вводим еще одно понятие (так ли оно нужно)
>Посмотрите, где вы видите код у меня?
>Только не формально, а содержательно.
между <??>, также как и интерпретатор
>Как {var}, так и <?=$var?> это семантически не код, а метки.
хорошо, значит метки
>Так же как {block ...} и <? form:: element(...)?> не код, а метки блоков в разных синтаксисах.
да понял уже, что это называется метка (хотя как не назови)
>Вы же опять тяните одеяло назад именно к самому настоящему коду, на несколько строк, с присвоениями и т. д.
php native предполагает настроящий код в шалонах. вы перешли от
код вынеситься в контроллер, блок остается в представлении
>Даже если код вынесен в один блок, это делает шаблон еще менее удобным в работе.
очень спорное заявление, особенно когда вы строите модульную маштабируемую систему
>Теперь придется приводить в соответствие имя поля и переменной, которые отделены возможно десятками или сотнями строк друг от друга.
не забывайте что придется приводить код который отвечает за получение данных из этой формы, в тех же сотнях строк от вас, хотя чаше просто в отдельном файле
>Тот идентификатор, который можно было написать один раз, у вас надо повторить дважды.
дернормализация, что поделать
>В таком случае лучше уж QuickForm.
)
>В статье как раз рассказывается, как я попытался убрать из шаблона код и оставить только метки.
те разделить логику и представление, замечательно
>Метки — неотъемлемая часть шаблона, даже если они сделаны в native PHP синтаксисе.
хорошо, вводим еще одно понятие (так ли оно нужно)
>Посмотрите, где вы видите код у меня?
>Только не формально, а содержательно.
между <??>, также как и интерпретатор
>Как {var}, так и <?=$var?> это семантически не код, а метки.
хорошо, значит метки
>Так же как {block ...} и <? form:: element(...)?> не код, а метки блоков в разных синтаксисах.
да понял уже, что это называется метка (хотя как не назови)
>Вы же опять тяните одеяло назад именно к самому настоящему коду, на несколько строк, с присвоениями и т. д.
php native предполагает настроящий код в шалонах. вы перешли от
код -> представление
к
метка(код) -> представление
код вынеситься в контроллер, блок остается в представлении
>Даже если код вынесен в один блок, это делает шаблон еще менее удобным в работе.
очень спорное заявление, особенно когда вы строите модульную маштабируемую систему
>Теперь придется приводить в соответствие имя поля и переменной, которые отделены возможно десятками или сотнями строк друг от друга.
не забывайте что придется приводить код который отвечает за получение данных из этой формы, в тех же сотнях строк от вас, хотя чаше просто в отдельном файле
>Тот идентификатор, который можно было написать один раз, у вас надо повторить дважды.
дернормализация, что поделать
>В таком случае лучше уж QuickForm.
)
Вы ошиблись в самом первом посыле:
> те разделить логику и представление, замечательно
Логика и представление уже давно отделены. Мы здесь работаем исключительно с представлением и его (представления) логикой. Логику представления никуда отделить нельзя и не надо. Ее можно лишь замаскировать. Как такое делается в «кучерявых» шаблонах ясно, а как сделать это наиболее элегантно в native PHP — тема данной статьи.
Возможно у вас другое понятие об элегантности, но в моем мире кусок HTML кода, заключенный в кавычки и передаваемый параметром куда-то — это не корректно. Я нашел достаточно дешевый способ как этого избегать и с вами им поделился. А теперь вы поясните вашу позицию, почему данный метод не имеет права на существование. Я не спрашиваю, что вы предлагаете взамен, поскольку вас «шаблон в кавычках», как я понимаю нисколько не смущает.
> те разделить логику и представление, замечательно
Логика и представление уже давно отделены. Мы здесь работаем исключительно с представлением и его (представления) логикой. Логику представления никуда отделить нельзя и не надо. Ее можно лишь замаскировать. Как такое делается в «кучерявых» шаблонах ясно, а как сделать это наиболее элегантно в native PHP — тема данной статьи.
Возможно у вас другое понятие об элегантности, но в моем мире кусок HTML кода, заключенный в кавычки и передаваемый параметром куда-то — это не корректно. Я нашел достаточно дешевый способ как этого избегать и с вами им поделился. А теперь вы поясните вашу позицию, почему данный метод не имеет права на существование. Я не спрашиваю, что вы предлагаете взамен, поскольку вас «шаблон в кавычках», как я понимаю нисколько не смущает.
>Логика и представление уже давно отделены.
хорошо, хорошо, не буду спорить.
>Возможно у вас другое понятие об элегантности, но в моем мире кусок HTML кода, заключенный в кавычки и передаваемый параметром куда-то — это не корректно.
это лишь один и вариантов, причем не самый хороший
>А теперь вы поясните вашу позицию, почему данный метод не имеет права на существование.
право на существование имеет любая идея, просто не все идеи одинакого хороши
остальное skiped
поясняю:
в контролере имеем привычное для любого программиста представление
<? php $form = new form();
$form->name = $name;
$form->test = $test;
$template->set('form', $form);
?>
в представлении имеем
<? php $form->start();?>
Name: Test: <? php $form->stop();?>
переведем в вид блоков для простоты {form}… {/form}, те для верстальшика вводиться только одна новая сущьность — блок form, в вашем случае вводиться куча сущьностей element, причем не стандартных, а в моем случае код стандартен.
про ошбики и возможность запутаться… тут есть 2 варианта:
— дебаг панель для верстальшика
— ошибки ловит программист, например с помошью автоматических тестов
хорошо, хорошо, не буду спорить.
>Возможно у вас другое понятие об элегантности, но в моем мире кусок HTML кода, заключенный в кавычки и передаваемый параметром куда-то — это не корректно.
это лишь один и вариантов, причем не самый хороший
>А теперь вы поясните вашу позицию, почему данный метод не имеет права на существование.
право на существование имеет любая идея, просто не все идеи одинакого хороши
остальное skiped
поясняю:
в контролере имеем привычное для любого программиста представление
<? php $form = new form();
$form->name = $name;
$form->test = $test;
$template->set('form', $form);
?>
в представлении имеем
<? php $form->start();?>
Name: Test: <? php $form->stop();?>
переведем в вид блоков для простоты {form}… {/form}, те для верстальшика вводиться только одна новая сущьность — блок form, в вашем случае вводиться куча сущьностей element, причем не стандартных, а в моем случае код стандартен.
про ошбики и возможность запутаться… тут есть 2 варианта:
— дебаг панель для верстальшика
— ошибки ловит программист, например с помошью автоматических тестов
Автора сделал свой выбор
Насяльника, опшипка однако ;)
Насяльника, опшипка однако ;)
Совсем затюкали несчастного автора.
Ну идея-то интересная.
Спасибо таки за статью ))
Ну идея-то интересная.
Спасибо таки за статью ))
К Хабракодерам: а в чём смысл тега code? (пояснение: он код всё равно каверкается)
К автору статьи: стало таки интересно разобраться в том, как вызов form:: element('name', $name) изменяет/использует последующий тег input. Попробовал скачать Phella CMF и разобраться, но сходу в исходники не врубился. Там используется буфферизация вывода и регекспы или как? Статья сильно бы выиграла, если бы вы ясно и понятно раскрыли тайну форменной магии.
Успехов.
К автору статьи: стало таки интересно разобраться в том, как вызов form:: element('name', $name) изменяет/использует последующий тег input. Попробовал скачать Phella CMF и разобраться, но сходу в исходники не врубился. Там используется буфферизация вывода и регекспы или как? Статья сильно бы выиграла, если бы вы ясно и понятно раскрыли тайну форменной магии.
Успехов.
У вас совершенно правильная догадка. Буферизируется блок текста, обрамленный двумя вызовами:
form:: element('name', $name)
и
form:: element()
Закрывающий тег блока может быть опущен, если за ним следует другой открывающий тег:
form:: element('name', $name)
и
form:: element('country', $country, $countries)
и
form:: element()
Содержимое буфера анализируется на предмет того, что нас интересует. В данном случае теги элементов формы. Но применять данную методу можно и не только для форм, а везде в «трудных» местах, чтобы сохранить чистый и опрятный HTML в шаблоне.
form:: element('name', $name)
и
form:: element()
Закрывающий тег блока может быть опущен, если за ним следует другой открывающий тег:
form:: element('name', $name)
и
form:: element('country', $country, $countries)
и
form:: element()
Содержимое буфера анализируется на предмет того, что нас интересует. В данном случае теги элементов формы. Но применять данную методу можно и не только для форм, а везде в «трудных» местах, чтобы сохранить чистый и опрятный HTML в шаблоне.
Спасибо за пояснение.
Может стоит попытаться сократить статью, но поместить туда эту инфу, увеличив информационную плотность текста? Ну да это ИМХО ))
Идея очень интересная, видимо напишу свою реализацию (код Phella CMF мне показался неудобоваримым).
Успехов.
Может стоит попытаться сократить статью, но поместить туда эту инфу, увеличив информационную плотность текста? Ну да это ИМХО ))
Идея очень интересная, видимо напишу свою реализацию (код Phella CMF мне показался неудобоваримым).
Успехов.
Дело в том, что та реализация завязана на используемую в фреймворке надстройку над HTTP. (Надстройка эта тоже очень нестандартная и вызвала бы бурю негодования, попади сюда.) Так например, там отсутствует второй параметр для form:: element, добавленый здесь, чтобы не смущать умы. Если требуется реализация, втыкаемая в любое «стандартное» место, то да, надо писать заново.
Можно написать именно в такой формулировке
stn.habrahabr.ru/blog/37247/#comment_871367
Детали не важны, а идея — хороша.
stn.habrahabr.ru/blog/37247/#comment_871367
Детали не важны, а идея — хороша.
Sign up to leave a comment.
Контекстные шаблоны в Native PHP