RomikChef
Да, читал статью, во многом согласен. Но всётаки это не то.
Я делал с подобным кодом ресурс, получается имхо не очень.
Ну вот пример:
]\')" onmousemove="show_Explanatory(\'explanatory_fly\', paste_name)" class="div_help hand">^ Имя: .html" onclick="infoWindow(this.href); return false;">
Комментарий:
Страницы: if($_GET["page"]==$i): ?>
else :?>
.html" class="bold color_1"> endfor;
?>
Ну как то всё это не очен.... В последнем цикле уж очень сильно представлено программирование. Плюс необходимость таскать массив $fornum, который содержит пределы для циклов... ну... не нравитца всё это..
Алексей:
В последнем цикле уж очень сильно представлено программирование.
а кто тебе мешал сгенерировать HTML блок ссылок непосредственно в скрипте, а в шаблоне этот блок выводить уже как
Какой бы хороший шаблонизатор ни был, он все равно будет вводить некоторые ограничения.
Кошмар!ты никогда не слышал об операторе foreach?
$weekday[$DHTML["weekday"][$i]] - ЧТО так трудно было викдэй положить в массив дхтмл?! чтобы вывод был единнобразным?
извини, но это твои личные косяки, а не подхода в целом.
всё это прекрасно причёывается, и выглядит, как
или, при использовании extract -
что не сложнее, чем
{USER_ID}
А со вторым циклом мне ОЧЕНЬ ИНТЕРЕСНО, как оно будет выглядеть в шаблоне, да.
Green Kakadu
нет, хтмл блок в скрипте - это плохо.
это смысл шаблонов теряется
Алексей по-моему, ты путаешь шаблоны с телепатией.
и находишься в плену весьма распространённого заблуждения о том, что можно в принципе разделить оформление и логику.
можно.
но кривизна будет немеряная.
RomikChef:
Green Kakadu
нет, хтмл блок в скрипте - это плохо.
это смысл шаблонов теряется
согласен, но в указанном примере хтмла минимум
RomikChef:
можно.
но кривизна будет немеряная.
угу + будет довольно много ограничений у такого шаблонизатора, либо добавляется еще одна шаблонизаторская прослойка, между шаблонами с "чисто" оформлением и самим скриптом
Green Kakadu
ух, ё.
прошу прощения, я сильно тормознул.
я подумал про первый блок, а речь - о втором.
Сермяжная правда этой жизни состоит в том, что именно как раз список страниц для навигации я сам как раз и формирую отдельным куском в скрипте.
И решения этой проблемы я не знаю.
И это меня напрягает.
Алексей
перед тем, как писать свой шаблонизатор, неплохо бы поизучать имеющиеся популярные решения (Smarty, pear::html::template::*, php-templates и т.д.).
RomikChef:
и находишься в плену весьма распространённого заблуждения о том, что можно в принципе разделить оформление и логику.
можно.
но кривизна будет немеряная.
возможно нахожусь.... а насчёт кривизны - но ведь как-то добиваются разработчики некривых решений!..
RomikChef:
Сермяжная правда этой жизни состоит в том, что именно как раз список страниц для навигации я сам как раз и формирую отдельным куском в скрипте.
И решения этой проблемы я не знаю.
т.е. хтмл в коде? так понимать?
Алексей:
но ведь как-то добиваются разработчики некривых решений!..
ПОКАЖЬ!!!
По гроб благодарен буду.
Лично мне пока некривого решения неизвестно.
Алексей:
т.е. хтмл в коде? так понимать?
Увы, да.
Впрочем, никто не мешает тебе поместить наоборот - код в хтмл, как сделано у тебя :-)
правда, опять же - почище.
Страницы: .html" class="bold color_1">
а вот тебе пример на чистых шаблонах:
{{TEMPLATE:PagesList_Item}}
{{?_Current}} {{_PageNo}}
{{?!_Current}} {{_PageNo}}
{{?/_Current}}
|
{{/TEMPLATE:PagesList_Item}}
оно тбе надо?
RomikChef
блин, сколько раз я поднимаю эту темы (или подобные им), ты всегда меня начинаешь переубеждать. И в принципе, тебе это удаётся.
Только вот ответь на вопрос - почему же практически во всех веб-мастерских используются шаблонизаторы?
[off]RomikChef:
По гроб благодарен буду.
Лично мне пока некривого решения неизвестно.
Я от своего шаблонизатора (KTempalte + доработка напильником) добился всего, чего хочется... Может, и над твоим решением поразмыслить всей толпой?
Алексей:
почему же практически во всех веб-мастерских используются шаблонизаторы?
Там,заметь, не просто шаблонизаторы, а движок+CMS+шаблонизатор. Даже если по отдельности каждый элемент г..., то связка иногда получается вполне функциональна[/off]
Я не то, чтобы переубеждаю.
Просто я пытаюсь и сам найти смысл.
Я могу наскрести пеару-тройку ответов на вопрос "почему используют". Но к вопросу "чем оно лучше" эти ответы не будут иметь отношения.
RomikChef:
Я могу наскрести пеару-тройку ответов на вопрос "почему используют".
давай! :)
а оно тебе надо?
1. Привычка с перла.
2. просчёты в расчётах(с). Те же заблуждения, что и у тебя. Люди на этапе создания думают, что шаблон получится простой и удобный.
3. забыл. потом вспомню.
RomikChef:
"почему используют". Но к вопросу "чем оно лучше" эти ответы не будут иметь отношения.
ИМХО используют чтоб править не код, а шаблон :) а код считается как вещь универсально работающая.
Но это не для того чтоб "человеку который ни хрена ни в чем не понимает" было проще - он и в шаблонах не поймет, а чтоб HTML вывод не растекался по всему коду скрипта (там чуть чуть, там что-то довывели в больших системах это вообще будет проблематично править), а находился в одном месте
RomikChef:
1. Привычка с перла.
кстати, здравая мысль.
На php система вывода о которой говорилось вначале по функциональности превосходит тот же HTML::Template, и при этом менее громоздка.
2. Идя к универсализации можно вообще уйти в некоторую абстракцию типа XSLT, но тогда нужно представлять для чего оно тебе надо, а не потому что это модно :)
по поводу XSLT:
Тест производительности XSLT процессоров для PHP/Perl (http://si.infonet.ee/projects/xslt-benchmark/)
XML+XSLT, чем лучше шаблонных движков, например Smarty? (http://phpclub.ru/talk/showthread.php?s=&threadid=57463) - показательная беседа переходящая в флейм (мне не нужен ни HTML ни XML, PHP рулез)
Green Kakadu:
а чтоб HTML вывод не растекался по всему коду скрипта
То есть, для обеспечения дисциплины?
шаблон, кстати, не панацея.
конгда мне приходилось раюботать с шаблонными движками, и в некоторых местах доводило до белого каления, я тупо писал в пхп-скрипте =тмл и вбивал его в вывод шаблона.
Алексей
3. Самое чудовищное заблуждение всех девелоперов, времён и народов - о том, что можно разделить "код" и "представление".
На самом деле, мы имеем "код приложения" и "код представления".
В представлении нам нужен КОД. От него никуда не деться.
Когда я столкнулся с XSLT, я впечатался в это понимание со всей дури.
ВСЕ создатели шаблонных движков движимы столь же благой, сколь ложной целью - разделение кода и представления.
и в результате у них получается новый язык.
RomikChef:
То есть, для обеспечения дисциплины?
шаблон, кстати, не панацея.
угу. знаешь это зависит больше от того кто как программирует. У некоторых вывод происходит довольно своеобразно - примерно так же как мысли которые влетают в голову и получается что черт ногу сломит пока разберешься в этой смеси кода (неважно php,perl) и html И алгоритм самого скрипта теряет ясность.
если чел-к пишет все подумав, а не по наитию, то в принципе он наверняка вывод как-то обособит от остального кода скрипта - там шаблонизатор и не нужен. правда, если рассматривать распределенную систему, состоящую из многих скриптов, типа скрипт форума - там замучаешься ползать по всем кодам в поисках хтмля.
RomikChef:
и в некоторых местах доводило до белого каления
согласен. иногда получается оч.извращенный и нечитабельный шаблон
Green Kakadu
я не понимаю - при чем здесь коды с хтм-лями?
чисто технически, шаблоны на пхп ничем не отличаются от обычных!
Они точно так же лежат в ОТДЕЛЬНЫХ ФАЙЛАХ!
И вопрос не в наитиях, конечно же, и не в собирании вывода в одном месте.
а в СОЗНАТЕЛЬНОМ разделении своих скриптов на КОД и ШАБЛОНЫ.
КОД подготавливает данные для шаблонов.
Шаблон - это файл с хтмл, в котором испольщуются операторы вывода, цикла и условного перехода.
Jean
на самом деле, не принимай близко к сердцу.
Людей, которые, как и ты, находятся в плену иллюзий, и не понимают элементарных вещей - очень много. Чудовищно много.
Понимающих, как раз - единицы.
Это ответ на вопрос Алексея, как раз.
Алексей - вот тебе живой пример, почему люди используют шаблонные движки.
от заблуждений.
Кстати, Алексей.
Это ещё один пункт.
Очень многие люди свято верят в то, что шаблон - это некое "оформление", удобное для верстальщика, а не ПРОГРАММА.
Обманывая себя и окружающих.
АГА!
Ты познакомься с шаблонами на XSLT
У тебя волосы дыбом встанут.
Это, якобы, язык написания шаблонов.
В нём ПХП программер ногу сломит - не то что верстальщик!
А все ради него, ради верстальщика! чтобы у него операторы программные были похожи на теги.
RomikChef:
с какой стати ПРОГРАММА должна быть похожа на УРОДСКИЙ язык форматирования?!
не программа, а код шаблона. И это так в идеале, который недостижим.
Green Kakadu
Ну, мы здесь не об идеалах разговариваем, а о реальности.
Давай об идеалах - во флейме?
А реальность такова, что шаблон - это программа.
Это ЛОГИКА ПРЕДСТАВЛЕНИЯ.
И чем раньше до девелопера доходит этот простой факт, тем ГОРАЗДО легче ему будет девелопить.
И тем прямее будут его шаблонные движки.
А у идеалистов получается идиотизм, когда они пытаются натянуть свой идеал на костлявый остов реальности. в которой в шаблоне логика обязательна.
И опять все кончается флеймом на пустом месте.
Есть 2 крайности:
1.Девелоперу с дизайнером требуется максимальная простота. (Вариант: дизайнер-дуб). Девелопер придумывает какую-то фигню, чтобы дать дизайнеру возможность менять его кривущщий ХТМЛ и не лезть руками в чистый код.
И именно здесь, а не где-то еще, лежит идея шаблонов. Максимально простых и понятных.
2.Девелоперу и дизайнеру нужна максимальная гибкость. И здесь простого и удобного решения пока не найдено (простого и понятного: XML+XSLT, Smarty и прочие навороты отпадают)
Так вот: максимальная гибкость - это и есть ПХП. На хрена городить огород в случае 2?
[off]Не ищите простого решения сложного вопроса.[/off]
RomikChef:
А реальность такова, что шаблон - это программа.
Это ЛОГИКА ПРЕДСТАВЛЕНИЯ.
шаблон это НЕ программа.
это скорее конфиг, конфиг же ты не называешь программой.
RomikChef:
в шаблоне логика обязательна
с этим трудно поспорить :)
RomikChef:
Это ЛОГИКА ПРЕДСТАВЛЕНИЯ.
в точку! Таким образом, использование шаблонизатора это не способ разделить логику и дизайн, а возможность вынести логику представления за пределы кода скрипта, и дать другим воз-ть менять эту логику особо не вдаваясь в детали того как это реализуется.
CGVictor
запомни.
шаблоны придуманы не для верстальщиков-идиотов.
шаблоны придуманы для того, чтобы можно было сделать страницу для печати НЕ ТРОГАЯ код скрипта.
Медитируй над этой истиной, пока она до тебя не дойдёт.
Green Kakadu:
шаблон это НЕ программа.
мне, в общем, всё равно - терминологическая ли это придирка, или ты действительно не понимаешь того, что шаблон - это именно программа. Во втором случае просто будет хуже только тебе.
если же вопрос в терминологии, то хоть флуктуатором назови - мне не жалко.
"программа" ли, "логика" ли - главное, чтобы смысл был понятен.
Другое дело, правда - из-за этого самообмана, когда программу называют чем угодно, но только не программой, и рождаются поверья о шаблонах
RomikChef:
Таким образом, использование шаблонизатора это не способ разделить логику и дизайн, а возможность вынести логику представления за пределы кода скрипта, и дать другим воз-ть менять эту логику.
правильно, только концовка от балды.
RomikChef:
особо не вдаваясь в детали того как это реализуется.
Как реализуется что?
на самом деле, шаблон - это возможность менять логику представления не вдаваясь в детали получения данных для этого шаблона. Т.е - в логику ПРИЛОЖЕНИЯ.
RomikChef:
чтобы можно было сделать страницу для печати НЕ ТРОГАЯ код скрипта
Вполне доступно. [off]Собственно, мое решение позволяет это делать.[/off] И эта истина мне понятна.
Те, кто хочеть влезть на елку и, простите, не ободрать задницу - придуман XML (и XSLT для него), милости прошу.
Или компромиссы. Но это - дело интимное.
CGVictor:
Собственно, мое решение позволяет это делать
собственно, ЛЮБОЙ шаблонный движок позволяет это сделать.
Другое дело - я не понимаю, зачем наживать себе геморрой, изобретая этот самый движок,если с задачей прекрасно справляется и сам пхп.
Макс, Сергей, вы не хотите высказаться? Жалко...
Алексей
Если подвести итог
Вот, что мы имеем на пхп:
]\')" onmousemove="show_Explanatory(\'explanatory_fly\', paste_name)" class="div_help hand">^
Имя:
.html" onclick="infoWindow(this.href); return false;">
Комментарий:
Страницы: .html" class="bold color_1"> Прежде, чем браться за темплейтный движок, подумай: а чем код на этом движке будет лучше, чем тот, который ты видишь здесь.
RomikChef:
Макс, Сергей, вы не хотите высказаться? Жалко...
Ну что вам написать ?
Я довольно долго использовал и шаблонизатор и чистый ПХП, сейчас изучаю XSLT.
ИМХО,
все 3 способа вполне примелемы и отличаются лишь мелочами, которые для кого-то
имеет значение, а для кого-то нет.
Например, я считаю, что в шаблоне должны быть доступны только те данные,
которые разрешил программист (это мое требование, которое никому не навязываю).
То есть если есть шаблон
то в нем не должны быть доступны переменным типа $db_login (логин доступа к БД).
В ПХП отделить пространство имен можно лишь двумя способами : помещение кода в функцию или класс (обычный include не подойдет).
Далее, мне при отладке удобно, что в шаблоне нет ПХП-кода.
Любые ПХП-ошибки (warning-и, notice-ы) надо искать именно в коде, а не в шаблоне.
Когда используешь шаблонизаторы, то любые ПХП-ошибки в броузер аккуратно выводятся сверху, а потом идет ХТМЛ-код (дизайн).
Но и классически шаблонизаторы меня не устраивают.
Причина, код скрипта кишит всякими :
$tpl->addBlockFile(\'content\', \'cb\', \'tth_list.html\');
if ($amount) {
$tpl->setCurrentBlock(\'row\');
while($list->isValid()) {
$thread= & $list->get();
$tpl->setVariable(array(
\'thread_id\' => $thread->id,
\'message\' => $thread->getMessage(),
\'subject\' => $thread->getSubject(),
));
$tpl->parseCurrentBlock();
$list->next();
}
} else {
$tpl->touchBlock(\'no_row\');
}
$tpl - это объект шаблонизатора.
Очень часто, если убрать всю работу с шаблонами, то скрипты оказываются очень
похожими, почти идентичными (это к вопросу о повторном использовании кода).
Поэтому я склоняюсь к использовнию шаблонизаторов, у которых шаблон имеет логику.
Выбор тут невелик - Smarty/XSLT/чистый PHP (Я склоняюсь к XSLT)
Противники таких шаблонов говорят что в шаблоне не должно быть никакой логики,
что они должны быть как можно более простыми.
1. Начнем с логики.
Логику в приложении можно разделить на 2 части: бизнес-логика (логика обработки данных) и логика представления (логика дизайна).
Так вот, верстальщик ДОЛЖЕН знать о логике представления. И он должен уметь управлять логикой представления.
Все что касается внешнего представления можно доверить верстальщику.
2. По поводу простоты шаблона.
Верстальщик должен быть таким же профи как и программист, только профи в своей области, в верстке.
Иначе пусть ищет другую работу.
Свое мнение не навязываю и не обсуждаю, хотя если есть вопросы - отвечу.
Макс:
Поэтому я склоняюсь к использовнию шаблонизаторов, у которых шаблон имеет логику.
Грубо говоря одна из целей этого решения - упростить свою работу и усложнить жизнь верстальщику :D
На самом деле, многие шутку не поймут.
На самом деле, такой подход развязывает руки верстальщику.
и он не должен бегать за каждым чихом к програмеру.
он имеет набдор данных, оговоренный в ТЗ и располагает так, как ему заблагорассудится
А убить доступ к переменным есть еще один способ - unset :-)
кроме шуток
foreach ($GLOBALS) убиваем все, что не $form_data
RomikChef
мдя... твои аргументы наповал убивают. Соглашусь со всем тобой сказанным, в т.ч. и с идеей, что с функциями шаблонизатора вполне справляется код на пхп, приведённый тобой.
Алексей
я так понял, что тут вопрос самодисциплины.
Но мне кажется, что соблюдать несложные правила синтаксиса, и в массив с данными помещать уже окончательно подготовленные данные - нет проблем.