На будущее: если цель иметь различные версии php/python/ruby и их библиотек,
нет смысла собирать отдельные контейнеры — достаточно phpbrew/rvm/virtualenv.
Шаблонизаторов много. Например, Twig и h2o имеют Django-подобный синтаксис, который также имеет и рубишный Liquid.
XSLT вообще никак не привязан к ЯП и может быть использован как «кроссплатформенный» шаблонизатор.
<?php if ($items) {
foreach ($items as $item) { ?>
<li><?= strtoupper ($item) ?></li>
<?php }} else { ?>
Записей нет
<?php } ?>
Smarty:
{foreach $items as $item}
<li>{$item|capitalize}</li>
{foreachelse}
Записей нет
{/foreach}
Django:
{% for item in items %}
<li>{{ item|upper }}</li>
{% else %}
Записей нет
{% endfor %}
Какой по вашему мнению вариант из первых двух проще трансформировать в третий?
Особенно человеку, незнакомому с PHP?
Учитывая что приведен лишь фрагмент шаблона?
Это простой пример и я нигде не говорил о Smarty (наоборот, считаю его отстойным).
Вы смешали теплое с мягким и слишком зациклены на слове «тяжелый».
Приведенный вами выше Blade — отнюдь не plain PHP, а шаблонизатор.
Что проще/нагляднее/читаемей:
<?php if ($items) {
foreach ($items as $item) { ?>
<li><?= strtoupper ($item) ?></li>
<?php }} else { ?>
Записей нет
<?php } ?>
// тоже самое, альтернативный синтаксис
<?php if ($items):
foreach ($items as $item): ?>
<li><?= strtoupper ($item) ?></li>
<?php endforeach;
else: ?>
Записей нет
<?php endif; ?>
или
{% for item in items %}
<li>{{ item|upper }}</li>
{% else %}
Записей нет
{% endfor %}
По-моему выбор очевиден. И меня совершенно не парит, что в PHP версии Х вдруг выпилят short tags или отключат их по дефолту.
Вообще, по-моему, Smarty и ему подобные шаблонизаторы действительно полезны в тех архитектурах, которые не были основаны на паттерне MVC, и, по сути, он просто реализует в них функционал представления. Но в современных PHP-фреймворках это ведь уже реализовано…
Современные PHP-фреймворки предлагают использовать шаблонизаторы, а не plain PHP.
В контексте MVC, шаблонизатор как раз разделяет представление от данных: вы можете манипулировать данными, но не можете их изменять. Соответственно, меньше шансов выстрелить себе в коленку. И по хорошему, шаблонизатор не должен давать выполнять произвольный код в шаблоне. Соответственно, шансов выстрелить себе в коленку еще меньше.
Как бонус более удобный рефакторинг: можно как угодно переименовать переменные в контроллере не опасаясь что сломается что-то в шаблоне.
Теперь про производительность: разумеется она будет ниже, чем у plain PHP, поскольку добавляется дополнительная абстракция.
Шаблонизаторы (если специально их не попросить) парсят шаблоны только один раз и сохраняют их на диск в виде plain PHP-файлов, которые затем постоянно используются. Каждый шаблонизатор справляется с данной задачей по разному.
Но в абсолютных цифрах — эта разница равна экономии на спичках и может приниматься во внимание только если у вас либо совсем бедовый хостинг, либо супер-пупер-мега-хайлоад и вы бодаетесь за каждую наносекунду.
У меня где-то был тест 5 или 6 различных шаблонизаторов, если найду, то поделюсь.
Легкая миграция шаблонов? Это вообще что такое?) И зачем оно нужно?) Куда их мигрировать из приложения?
Существуют другие ЯП, помимо PHP, и иногда возникает необходимость переписать часть на них.
Так вот, если я захочу переписать с PHP на Ruby/Python, то с вменяемым шаблонизатором правка существующих шаблонов будет минимальна. Это перспектива.
А вот суровая жизнь: на нескольких проектах у нас используются одновременно php, java, python, и при этом шаблоны у них общие. Потребуется завтра нода, руби или любой другой язык, в шаблоны даже лезть не придется.
Ну так зачем нужны эти тяжелые шаблонизаторы, когда и без них всё прекрасно работает?)
Затем же за чем нужны фрэймворки.
Затем же за чем нужны ORM.
Затем же за чем нужнo PDO.
Без всех перечисленных тоже можно обойтись (в некоторых случаях даже стоит обойтись) и прекрасно работать.
Smarty далеко не единственный и не лучший шаблонизатор.
Если вы строите свои суждения на единственном печальном опыте — это ваше право, но картинку не расскрывает.
Дальнейший разговор невозможен, так как кроме smarty вы ничего другого не видали.
К тому же, они резко усложняют архитектуру приложения, а также в десятки раз увеличивает время генерации одной станицы сайта.
Ерунда.
Резкого усложнения архитектуры нет.
Десятков раз тоже нет (вернее такие слоупоки есть, но никто не заставляет их использовать).
Любой шаблонизатор будет медленнее, но взамен они предоставляют:
— чистый и легкочитаемый код
— простой синтаксис, которому без труда можно научить верстальщиков
— легкая миграция шаблонов между платформами (если специально озадачится, то и вовсе плтаформонезависимые шаблоны).
В большинстве случаев в битве «скорость рендеринга страницы vs скорость/удобство разработки» побеждает второе, потому что нет разницы страница будет отрисована чистым PHP за 10 мс или шаблонизатором за 100 мс.
По этой же причине популярны и широко используются различные фреймворки и ORM.
Возможно, меня не правильно поняли: я отнюдь не vim-хэйтер.
И все мои комментарии не о том, что vim отстой, а что статья отстой и содержимое не соответствует заголовку.
У vim — свои сильные стороны, у ide свои. Частично они пересекаются, но не во всем.
Если в vim когда-нибудь появится тот функционал, который мне дает ide (и который я использую), то я бы дал ему шанс. А там кто знает, может быть и пересел.
То есть половина того функционала, что есть в JetBrains продуктах, программист, не желающий лазить по менюшкам, будет выполнять через консоль? Зачем тогда этот функционал нужен?
Вы привели пример, я вам ответил что в IDE это можно сделать практически аналогично, если есть желание. При этом не нужно ничего настраивать в самой IDE: приведенные алиасы живут в rc-файле и используются в любом терминале в системе.
А как на счет того, чтобы я нажал прямо в редакторе gb, и мне, в соседнем окошке, открылся список веток репозитория. Можно еще с помощью консоли сделать так, чтобы я выставил текстовый курсор на нужную мне ветку и нажал Enter, при этом весь проект изменился в соответствии с этой веткой?
По хоткею открывается окно со списком веток. Набирая название ветки, дерево сразу же фильтруется. По Enter загружается ветка.
Ни одного движения мышью. Внезапно?
Если человек разберется с фреймворком, он тем более разберется с «говнокодом».
Фреймворк надо учить не в плане «тут контроллер, здесь моделька, тяп-ляп пару методов и готово», а вникать каким образом это реализовано и почему.
Речь шла о персональной покупке, соответственно и цену указал персональной лицензии.
EAP — крайний легальный вариант, если уж не купить никак.
Среди моих знакомых есть люди вполне довольные eclipse/aptana, как по мне они слишком неповоротливы. Думаю дело здесь опять же в привычке.
Netbeans вполне неплох. Единственное (что я могу припомнить) — это весьма скудные (на момент использования) возможности по форматированию кода и работы с БД. Что в итоге и привело меня к jetbrains.
Python точно ставится, про остальное не скажу так как пользуюсь не IDEA, а другими их продуктами.
$200 за продукт, который можно превратить в dev-комбайн чуть ли не для всего, ИМХО, не заоблачная цена для программиста, который этим зарабатывает (да и по хорошему это должен делать работодатель).
К тому же у них есть бесплатные лицензии для студентов и опенсорсных проектов. Да EAP тот же.
А ведь еще есть netbeans c eclipse, которые многое умеют и совсем бесплатные.
нет смысла собирать отдельные контейнеры — достаточно phpbrew/rvm/virtualenv.
Шаблонизаторов много. Например, Twig и h2o имеют Django-подобный синтаксис, который также имеет и рубишный Liquid.
XSLT вообще никак не привязан к ЯП и может быть использован как «кроссплатформенный» шаблонизатор.
Smarty:
Django:
Какой по вашему мнению вариант из первых двух проще трансформировать в третий?
Особенно человеку, незнакомому с PHP?
Учитывая что приведен лишь фрагмент шаблона?
Это простой пример и я нигде не говорил о Smarty (наоборот, считаю его отстойным).
Приведенный вами выше Blade — отнюдь не plain PHP, а шаблонизатор.
Что проще/нагляднее/читаемей:
или
По-моему выбор очевиден. И меня совершенно не парит, что в PHP версии Х вдруг выпилят short tags или отключат их по дефолту.
Современные PHP-фреймворки предлагают использовать шаблонизаторы, а не plain PHP.
В контексте MVC, шаблонизатор как раз разделяет представление от данных: вы можете манипулировать данными, но не можете их изменять. Соответственно, меньше шансов выстрелить себе в коленку. И по хорошему, шаблонизатор не должен давать выполнять произвольный код в шаблоне. Соответственно, шансов выстрелить себе в коленку еще меньше.
Как бонус более удобный рефакторинг: можно как угодно переименовать переменные в контроллере не опасаясь что сломается что-то в шаблоне.
Теперь про производительность: разумеется она будет ниже, чем у plain PHP, поскольку добавляется дополнительная абстракция.
Шаблонизаторы (если специально их не попросить) парсят шаблоны только один раз и сохраняют их на диск в виде plain PHP-файлов, которые затем постоянно используются. Каждый шаблонизатор справляется с данной задачей по разному.
Но в абсолютных цифрах — эта разница равна экономии на спичках и может приниматься во внимание только если у вас либо совсем бедовый хостинг, либо супер-пупер-мега-хайлоад и вы бодаетесь за каждую наносекунду.
У меня где-то был тест 5 или 6 различных шаблонизаторов, если найду, то поделюсь.
Так вот, если я захочу переписать с PHP на Ruby/Python, то с вменяемым шаблонизатором правка существующих шаблонов будет минимальна. Это перспектива.
А вот суровая жизнь: на нескольких проектах у нас используются одновременно php, java, python, и при этом шаблоны у них общие. Потребуется завтра нода, руби или любой другой язык, в шаблоны даже лезть не придется.
Затем же за чем нужны фрэймворки.
Затем же за чем нужны ORM.
Затем же за чем нужнo PDO.
Без всех перечисленных тоже можно обойтись (в некоторых случаях даже стоит обойтись) и прекрасно работать.
Smarty далеко не единственный и не лучший шаблонизатор.
Если вы строите свои суждения на единственном печальном опыте — это ваше право, но картинку не расскрывает.
Дальнейший разговор невозможен, так как кроме smarty вы ничего другого не видали.
Резкого усложнения архитектуры нет.
Десятков раз тоже нет (вернее такие слоупоки есть, но никто не заставляет их использовать).
Любой шаблонизатор будет медленнее, но взамен они предоставляют:
— чистый и легкочитаемый код
— простой синтаксис, которому без труда можно научить верстальщиков
— легкая миграция шаблонов между платформами (если специально озадачится, то и вовсе плтаформонезависимые шаблоны).
В большинстве случаев в битве «скорость рендеринга страницы vs скорость/удобство разработки» побеждает второе, потому что нет разницы страница будет отрисована чистым PHP за 10 мс или шаблонизатором за 100 мс.
По этой же причине популярны и широко используются различные фреймворки и ORM.
И все мои комментарии не о том, что vim отстой, а что статья отстой и содержимое не соответствует заголовку.
У vim — свои сильные стороны, у ide свои. Частично они пересекаются, но не во всем.
Если в vim когда-нибудь появится тот функционал, который мне дает ide (и который я использую), то я бы дал ему шанс. А там кто знает, может быть и пересел.
Какой поставите в настройках, такой и будет.
Он тоже есть.
И давайте на этом остановимся, иначе останемся без субботы.
Хотя, как по мне, ему есть нативные альтернативы.
По хоткею открывается окно со списком веток. Набирая название ветки, дерево сразу же фильтруется. По Enter загружается ветка.
Ни одного движения мышью. Внезапно?
Поэтому (у меня):
gc — git commit
gca — git commit -a
gp — git push
gl — git pull
и т.д.
алиасов можно настрогать каких угодно.
Фреймворк надо учить не в плане «тут контроллер, здесь моделька, тяп-ляп пару методов и готово», а вникать каким образом это реализовано и почему.
EAP — крайний легальный вариант, если уж не купить никак.
Среди моих знакомых есть люди вполне довольные eclipse/aptana, как по мне они слишком неповоротливы. Думаю дело здесь опять же в привычке.
Netbeans вполне неплох. Единственное (что я могу припомнить) — это весьма скудные (на момент использования) возможности по форматированию кода и работы с БД. Что в итоге и привело меня к jetbrains.
$200 за продукт, который можно превратить в dev-комбайн чуть ли не для всего, ИМХО, не заоблачная цена для программиста, который этим зарабатывает (да и по хорошему это должен делать работодатель).
К тому же у них есть бесплатные лицензии для студентов и опенсорсных проектов. Да EAP тот же.
А ведь еще есть netbeans c eclipse, которые многое умеют и совсем бесплатные.