Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Статья для новичков писалась. Опытному человеку она может показаться неактуальной конечно.
Статья отличная. Я вот захотел изучить веб программинг, имея достаточно большой опыт программинга вне веба — и могу сказать, что статья очень полезная. Хотя конечно мало, хочется такого материала гораздо больше. Именно такого, приглашающего к размышлению, а не мануалов типа «ткните сюда, вставьте это — и вот вам супер приложение».
Куча текста ни о чем, который не хочется читать.
А кто автор статьи?
А вы "слегка" не подумали что с таким же успехом верстальщик может легко выучить конструкции if..else и foreach на чистом PHP, две-три функции получения данных, и писать на нормальном PHP не заучивая тонны "строгого синтаксиса" ?
При соблюдении корпоративного стандарта - нельзя!
А на смарти так же можно наговнокодить.
Поэтому ваши доводы абсолютно бессмысленны.
А на смарти так же можно наговнокодить.
Поэтому ваши доводы абсолютно бессмысленны.
не встречал еще ни одного хостера который бы отключал short_open_tag, к томуже по дефолту она включена
Да што вы, любой верстальщег будет прыгать от радости, встретив подобный код:
{else}
{section name=field_loop loop=$fields}
<tr>
<td class='form1'>{$fields[field_loop].field_title}{if $fields[field_loop].field_required != 0}*{/if}</td>
<td class='form2'>
{if $fields[field_loop].field_id == 5}
<select name='field_{$fields[field_loop].field_id}' id='ajax_city' val='{$fields[field_loop].field_value}' style='width: 200px'></select>
{/if}
{if $fields[field_loop].field_id == 1}
<select name='field_{$fields[field_loop].field_id}' id='ajax_country' val='{$fields[field_loop].field_value}' onchange="loadInfo('#ajax_city', 'cities', '&country='+this.value, this)" style='width: 200px'></select>
{/if}
{if $fields[field_loop].field_id == 2}
<div><input type='text' class='text' name='field_2' value='{$fields[field_loop].field_value}' style='{$fields[2].field_style}' maxlength='{$fields[field_loop].field_maxlength}'></div>
<div class='form_desc'>{$fields[field_loop].field_desc}</div>
{/if}
</td>
</tr>
{/section}
{/if}
{else}
{section name=field_loop loop=$fields}
<tr>
<td class='form1'>{$fields[field_loop].field_title}{if $fields[field_loop].field_required != 0}*{/if}</td>
<td class='form2'>
{if $fields[field_loop].field_id == 5}
<select name='field_{$fields[field_loop].field_id}' id='ajax_city' val='{$fields[field_loop].field_value}' style='width: 200px'></select>
{/if}
{if $fields[field_loop].field_id == 1}
<select name='field_{$fields[field_loop].field_id}' id='ajax_country' val='{$fields[field_loop].field_value}' onchange="loadInfo('#ajax_city', 'cities', '&country='+this.value, this)" style='width: 200px'></select>
{/if}
{if $fields[field_loop].field_id == 2}
<div><input type='text' class='text' name='field_2' value='{$fields[field_loop].field_value}' style='{$fields[2].field_style}' maxlength='{$fields[field_loop].field_maxlength}'></div>
<div class='form_desc'>{$fields[field_loop].field_desc}</div>
{/if}
</td>
</tr>
{/section}
{/if}
пхп имеет такой же строгий синтаксис, достаточно написать внутрикорпоративную шпаргалку по пхп-шному синтаксису на 2 листа А4. А верстальщик, если он не тупая амеба без мозга, освоит это так же быстро как и смарти.
Мне, как программисту вообще было очень странно читать мануал по синтаксису языка в языке, который изначально был ориентирован на использование в связке с html. Так же сложно использовать то, что не очень понимаешь как оно работает. А смарти-конструкция foreach меня вообще бесит, она не похожа ни на что другое, что используется в других языках. Как она работает?.. Зачем эта прослойка вообще нужна?..
Из объективных плюсов Смарти могу назвать только кеширование, хотя большинство фрейворков уже имеют инструменты для кеширования.
- Что сложнее будет понять верстальщику
<?if (!empty($arResult)):?>
<?foreach($arResult as $arItem):?>
или
{foreach from=$myArray item=foo}
<li>{$foo}</li>
Если не ориентироваться на тупую амебу, то ответ очевиден.
- Запрет вывода ошибок пользователям? error_reporting(0)
- Встроенные функции? Это прерогатива цмски. Какая хер разница верстальщику читать описание десятка функций цмски, которые он может использовать в шаблонах, или тоже самое в доке по смарти?..
- Скорость разработки? А программистам не пофиг что писать?
$view->Assign('var', $var);
или
$smarty->Assign('var', $var);
Вообще если так рассуждать, то верстальщик должен владеть еще и javascsript'ом. А если он js-кодер, то использование специфичных функций цмски ему будет так же привычно.
Мне, как программисту вообще было очень странно читать мануал по синтаксису языка в языке, который изначально был ориентирован на использование в связке с html. Так же сложно использовать то, что не очень понимаешь как оно работает. А смарти-конструкция foreach меня вообще бесит, она не похожа ни на что другое, что используется в других языках. Как она работает?.. Зачем эта прослойка вообще нужна?..
Из объективных плюсов Смарти могу назвать только кеширование, хотя большинство фрейворков уже имеют инструменты для кеширования.
- Что сложнее будет понять верстальщику
<?if (!empty($arResult)):?>
<?foreach($arResult as $arItem):?>
или
{foreach from=$myArray item=foo}
<li>{$foo}</li>
Если не ориентироваться на тупую амебу, то ответ очевиден.
- Запрет вывода ошибок пользователям? error_reporting(0)
- Встроенные функции? Это прерогатива цмски. Какая хер разница верстальщику читать описание десятка функций цмски, которые он может использовать в шаблонах, или тоже самое в доке по смарти?..
- Скорость разработки? А программистам не пофиг что писать?
$view->Assign('var', $var);
или
$smarty->Assign('var', $var);
Вообще если так рассуждать, то верстальщик должен владеть еще и javascsript'ом. А если он js-кодер, то использование специфичных функций цмски ему будет так же привычно.
спорить об удобстве таких конструкций - это все равно что спорить о музыке =)
Это странно считать, что удобство и читаемость кода повышает замена одной скобочки на другую. Я не вижу принципиальной разницы в этом. О специфических серверах я не буду говорить, так как точно так же можно вспомнить о серверах, где смарти будет тормозить всю систему, если ему не дадут достаточно ресурсов. Был у меня один такой интернет-магазин.
Мне удобно читать и понимать такую конструкцию и замена одной скобочки на другую не влияет ни на что:
<?if ($arParams['displayLink']):?><a href="...">link</a>
При этом также можно использовать extract_vars для массива параметров.
Это странно считать, что удобство и читаемость кода повышает замена одной скобочки на другую. Я не вижу принципиальной разницы в этом. О специфических серверах я не буду говорить, так как точно так же можно вспомнить о серверах, где смарти будет тормозить всю систему, если ему не дадут достаточно ресурсов. Был у меня один такой интернет-магазин.
Мне удобно читать и понимать такую конструкцию и замена одной скобочки на другую не влияет ни на что:
<?if ($arParams['displayLink']):?><a href="...">link</a>
При этом также можно использовать extract_vars для массива параметров.
Всё таки согласен. Разделять логику от представления — надо. Но придумывать для этого новый отдельный язык — это по меньшей мере глупо.
А мне xslt нравится =)
Статья, написанная 2 года назад, в текущем времени - ни о чем.
Статья, написанная 2 года назад, в текущем времени - ни о чем.
Еще хочется услышать мнение об одном аспекте - это кеширование такого кода.
ob_start()
...
ob_get_clean()
вполне достаточный метод?
Смарти пользовался, но я до сих пор не могу понять, нафига исполнять еще кучу кода, замедляющего приложение, если тоже самое делается на голом пхп быстрее и проще. Доводы за использование смарти так и не могут убдеить меня применять его в своих проектах.
ob_start()
...
ob_get_clean()
вполне достаточный метод?
Смарти пользовался, но я до сих пор не могу понять, нафига исполнять еще кучу кода, замедляющего приложение, если тоже самое делается на голом пхп быстрее и проще. Доводы за использование смарти так и не могут убдеить меня применять его в своих проектах.
Полезная статья. Читается легко. Сам пришёл к выводу что Смарти не нужен. А нужен свой "шаблонизатор", то есть, возможность удобный код, с помощью которого можно вставлять данные в HTML... <\h1\>Привет, <\?=Output::get('username')\?><\/h1\> ну вы поняли...
Ну вот, потихоньку осознали значимость статьи. Пошли холивары, хотя кажется ни те ни те статью так и не прочли.
Да, вообще впринципе наболевшая тема - отделение модели от представления, некоторые даже пытаются реализовать шаблонизатор так, что в нем вообще как факт отсутвуют элементы логики, а вся логика реализуется в коде...
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.
Согласен с тем, что ЛОГИКУ разделять надо. А не логику и представление.
А пользоваться шаблонизаторами, или писать свои, или вообще на голом РНР делать - выбор каждого свой, и зависеть будет от предпочтений и требований.
Главное, что бы потом не встречать в файле код на пхп, потом на хтмл, всредине которого вызываются какие-то объекты, функции, совершаются действия с базой, а потом опять хтмл.
Логика представления:
есть переменная - распечать.
есть массив - распечатать значения и ключи в удобном виде (таблица, селект бокс и т.д.)
можно еще всякие сравнения проводить не сложные.
И важно, что бы потом кодом хтмл можно было воротить как хочешь. А то если будет как я сказал в самом начале, то что перенести тот же селект бокс нужно перелопатить кучу РНР кода, и это займет пол дня. А заказчик скажет - "ёкалэмэнэ, это же только вот эту штучку туда перенести!", фигли полдня?
А пользоваться шаблонизаторами, или писать свои, или вообще на голом РНР делать - выбор каждого свой, и зависеть будет от предпочтений и требований.
Главное, что бы потом не встречать в файле код на пхп, потом на хтмл, всредине которого вызываются какие-то объекты, функции, совершаются действия с базой, а потом опять хтмл.
Логика представления:
есть переменная - распечать.
есть массив - распечатать значения и ключи в удобном виде (таблица, селект бокс и т.д.)
можно еще всякие сравнения проводить не сложные.
И важно, что бы потом кодом хтмл можно было воротить как хочешь. А то если будет как я сказал в самом начале, то что перенести тот же селект бокс нужно перелопатить кучу РНР кода, и это займет пол дня. А заказчик скажет - "ёкалэмэнэ, это же только вот эту штучку туда перенести!", фигли полдня?
Спасибо за статью, ликвидировал пробел в своих знаниях)
По-моему, шаблонизатор — очень важная часть в комерческих проектах. И главное его достоинство — именно отсутсвие логики ( html + {тег} ). + Шаблонизатор должен быть не сложным в понимании, и не сложным в написании модулей для этого же проекта ( минимум кода, максимум работы )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вся правда о шаблонизаторах