Comments 48
UFO just landed and posted this here
Статья для новичков писалась. Опытному человеку она может показаться неактуальной конечно.
Статья отличная. Я вот захотел изучить веб программинг, имея достаточно большой опыт программинга вне веба — и могу сказать, что статья очень полезная. Хотя конечно мало, хочется такого материала гораздо больше. Именно такого, приглашающего к размышлению, а не мануалов типа «ткните сюда, вставьте это — и вот вам супер приложение».
Куча текста ни о чем, который не хочется читать.
А кто автор статьи?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
А вы "слегка" не подумали что с таким же успехом верстальщик может легко выучить конструкции if..else и foreach на чистом PHP, две-три функции получения данных, и писать на нормальном PHP не заучивая тонны "строгого синтаксиса" ?
UFO just landed and posted this here
При соблюдении корпоративного стандарта - нельзя!
А на смарти так же можно наговнокодить.
Поэтому ваши доводы абсолютно бессмысленны.
А на смарти так же можно наговнокодить.
Поэтому ваши доводы абсолютно бессмысленны.
UFO just landed and posted this here
не встречал еще ни одного хостера который бы отключал 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-кодер, то использование специфичных функций цмски ему будет так же привычно.
UFO just landed and posted this here
UFO just landed and posted this here
спорить об удобстве таких конструкций - это все равно что спорить о музыке =)
Это странно считать, что удобство и читаемость кода повышает замена одной скобочки на другую. Я не вижу принципиальной разницы в этом. О специфических серверах я не буду говорить, так как точно так же можно вспомнить о серверах, где смарти будет тормозить всю систему, если ему не дадут достаточно ресурсов. Был у меня один такой интернет-магазин.
Мне удобно читать и понимать такую конструкцию и замена одной скобочки на другую не влияет ни на что:
<?if ($arParams['displayLink']):?><a href="...">link</a>
При этом также можно использовать extract_vars для массива параметров.
Это странно считать, что удобство и читаемость кода повышает замена одной скобочки на другую. Я не вижу принципиальной разницы в этом. О специфических серверах я не буду говорить, так как точно так же можно вспомнить о серверах, где смарти будет тормозить всю систему, если ему не дадут достаточно ресурсов. Был у меня один такой интернет-магазин.
Мне удобно читать и понимать такую конструкцию и замена одной скобочки на другую не влияет ни на что:
<?if ($arParams['displayLink']):?><a href="...">link</a>
При этом также можно использовать extract_vars для массива параметров.
UFO just landed and posted this here
Всё таки согласен. Разделять логику от представления — надо. Но придумывать для этого новый отдельный язык — это по меньшей мере глупо.
UFO just landed and posted this here
А мне xslt нравится =)
Статья, написанная 2 года назад, в текущем времени - ни о чем.
Статья, написанная 2 года назад, в текущем времени - ни о чем.
Еще хочется услышать мнение об одном аспекте - это кеширование такого кода.
ob_start()
...
ob_get_clean()
вполне достаточный метод?
Смарти пользовался, но я до сих пор не могу понять, нафига исполнять еще кучу кода, замедляющего приложение, если тоже самое делается на голом пхп быстрее и проще. Доводы за использование смарти так и не могут убдеить меня применять его в своих проектах.
ob_start()
...
ob_get_clean()
вполне достаточный метод?
Смарти пользовался, но я до сих пор не могу понять, нафига исполнять еще кучу кода, замедляющего приложение, если тоже самое делается на голом пхп быстрее и проще. Доводы за использование смарти так и не могут убдеить меня применять его в своих проектах.
Полезная статья. Читается легко. Сам пришёл к выводу что Смарти не нужен. А нужен свой "шаблонизатор", то есть, возможность удобный код, с помощью которого можно вставлять данные в HTML... <\h1\>Привет, <\?=Output::get('username')\?><\/h1\> ну вы поняли...
Ну вот, потихоньку осознали значимость статьи. Пошли холивары, хотя кажется ни те ни те статью так и не прочли.
Да, вообще впринципе наболевшая тема - отделение модели от представления, некоторые даже пытаются реализовать шаблонизатор так, что в нем вообще как факт отсутвуют элементы логики, а вся логика реализуется в коде...
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.
Согласен с тем, что ЛОГИКУ разделять надо. А не логику и представление.
А пользоваться шаблонизаторами, или писать свои, или вообще на голом РНР делать - выбор каждого свой, и зависеть будет от предпочтений и требований.
Главное, что бы потом не встречать в файле код на пхп, потом на хтмл, всредине которого вызываются какие-то объекты, функции, совершаются действия с базой, а потом опять хтмл.
Логика представления:
есть переменная - распечать.
есть массив - распечатать значения и ключи в удобном виде (таблица, селект бокс и т.д.)
можно еще всякие сравнения проводить не сложные.
И важно, что бы потом кодом хтмл можно было воротить как хочешь. А то если будет как я сказал в самом начале, то что перенести тот же селект бокс нужно перелопатить кучу РНР кода, и это займет пол дня. А заказчик скажет - "ёкалэмэнэ, это же только вот эту штучку туда перенести!", фигли полдня?
А пользоваться шаблонизаторами, или писать свои, или вообще на голом РНР делать - выбор каждого свой, и зависеть будет от предпочтений и требований.
Главное, что бы потом не встречать в файле код на пхп, потом на хтмл, всредине которого вызываются какие-то объекты, функции, совершаются действия с базой, а потом опять хтмл.
Логика представления:
есть переменная - распечать.
есть массив - распечатать значения и ключи в удобном виде (таблица, селект бокс и т.д.)
можно еще всякие сравнения проводить не сложные.
И важно, что бы потом кодом хтмл можно было воротить как хочешь. А то если будет как я сказал в самом начале, то что перенести тот же селект бокс нужно перелопатить кучу РНР кода, и это займет пол дня. А заказчик скажет - "ёкалэмэнэ, это же только вот эту штучку туда перенести!", фигли полдня?
Спасибо за статью, ликвидировал пробел в своих знаниях)
По-моему, шаблонизатор — очень важная часть в комерческих проектах. И главное его достоинство — именно отсутсвие логики ( html + {тег} ). + Шаблонизатор должен быть не сложным в понимании, и не сложным в написании модулей для этого же проекта ( минимум кода, максимум работы )
Sign up to leave a comment.
Вся правда о шаблонизаторах