Скажите это ребятам отсюда http://sensiolabs.com
Или отсюда http://knplabs.com
Или ему https://sebastian-bergmann.de
И ему в придачу http://martinfowler.com

А сообществу в этом форуме предоставьте пруфу, подтверждающие Ваши слова. Именно про "нубство".

_____________
PHP: The Right Way
Бесплатное обучение Symfony2

Tox: 55BB67DE54B1CB14F8C37B4F3AED64E6A45922988D22F85EF75039751F26F05460664D978F5C

Твин писал свой шаблонизатор)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Это называется ООП ради ООП и вы правы - это нубство.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Я серьёзно не понимаю, зачем вообще написали TWIG. Без него можно прекрасно обойтись, что кстати многие и делают, когда дело касается оптимальности, а не лени в разработке. Но это вопрос другой.

Мне непонятно, зачем он грузит всё это:

для генерации ооочень простой странички. Ведь не на всех есть формы с 100500 полями))) Ну есть одна - две допустим, а остальные как?

А делает это он исключительно потому, что иначе не может. По сути не может. Ибо написан на ООП парадигме.

Я написал ради спортивного интереса свой шаблонизатор. Аналог XTemplate по синтаксису. Он поддерживает наследования шаблонов и несколько других, действительно необходимых шаблонизатору, функций. Это не процедурка естественно, это класс. Один! 676 строк вместе с промышленными комментариями. И он выполняет свою, узко поставленную задачу, так как является дискретной частью системы. И "Привет, Мир!" он распарсит за микросекунду, не причиняя никаких неудобств серверу. В отличие от.

Вот таким по моему мнению и должен быть шаблонизатор. Скрипт, работающий с шаблонами, а не подменяюший логику PHP. Потому что логика не должна быть реализована в шаблонизаторе. Он не должен ескейпить данные, не должен менять кодировку, не должен повторять штатные функции плана number_format() и иже с ними. Это всё можно нужно делать по мере надобности в логике скрипта.

Ибо получается это не шаблонизатор, а фреймворк уже.

Ну и соответственно он тащит этот весь хлам в оперативку, насилует ФС, жрет время и ресурс. Потому что да, такой огромный функционал нельзя написать в три строки. Нужно 89 файлов. Ну и естественно без ООП не обойтись. Оно же нужно всё и сразу))) Потому и говорю, это горе от ума.

И еще. Не нужно говорить про мой тут авторитет. Это звучит, как будто если бы не, то мне вообще по сопатке дать и успокоиться. Я сейчас обычный форумчанин, раз ввязался в холивар. И имею право свои взгляды отстаивать на равных. Такие фразы хуже плевка в лицо. Шутка.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Приведенный комментарий был верным. Привет мир не нужно писать на ООП. Можно обойтись одной строчкой кода) Вы же сами сказали, не нужно притягивать за уши задачи, в которых применения данных инструментов заведомо неверно)

Класс - можно назвать небольшим пакетом, в котором по смыслу собран небольшой набор переменных и функций, чтобы не городить 1 безумную функцию с различными if-else. ООП начинается тогда, когда вступает в силу взаимодействие между двумя классами, да не просто вызов, а именно наследование и другие заумные словечки

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

Я был одним из этих многих. Не понравилось. Про оптимальность вопрос спорный. Кэширование шаблонов никто не отменял.

Как и про лень. Знаете, бытует одно мнение. Чем middle отличается от senior'а? Middle думае о том, как рещить задачу более изящно/оптимально/правильно. Senior думает, как съэкономить деньги заказчика. Так вот устранение причины любой лени (создание соответвующих интсрументов) - это прямая экономия денег заказчика.

Вот за это неистово плюсую ))
Тут мы подходим к капитанскому выводу: каждой задаче подходящий инструмент. Если мы (гиботетическая команда разработчиков) не умеем/не можем делать подругому, иначе как:

твиг нам в помощь. Для хеллоувордов, соостветсвенно, нативный php. Ну а если мы имеем время/деньги на создание своего инструмента с блекждеком, который наиболее подходяще решает класс задач, с которыми мы часто сталкиваемся, почему бы и нет? Хотя, лично я стараюсь ибегать своих велосипедов. В крайнем случаее, оформляем по всем правилам общедоступной либы (сейчас в php мэйнстрим - это поддержка composer'а) и выкладываем на github.

А что, собственно, плохого в 89 файлах?
Пример из жизни. В одной крупной соц. сети, в которой я работал, решили провести день оптимизации. В рамках этого дня был оптимизирован автозагрузчик классов. Посчитали, выяснили что эта оптимизация экономит 15000 в месяц. На поиск узкого места и оптимизацию программист затратил примерно 1 день - 8 часов. Зп у программиста тогда была примерно 100к, т.е. ~4.5к стоила компании это оптимизация. 15к ежемесяно против 4.5к единоразово - выгодное вложение. Но самая главная цифра в этом примере DAU соцсети - 800-900к иногда переваливающее за 1м. Много Вы знаете сайтов с такой же посещаемостью? Я - нет. Сколько будут стоить эти 89 файлов для среднестатистического интернет-магазина? Не знаю, но явно много меньше, чем стоимость времени разработчиков, если они решат вьюхи на нативном php писать.

И на последок))

Никоем образом не хотел оскорбить. Просто, любые слова имеют последствие. И чем больше авторитет их высказавшего, тем больше последствий. Никогда нельзя забывать об этом, даже если очень хочется) Но это уже совсем оффтоп, не будем ))

PS: себя считаю мидлом, но деньги ещё с юниорских времён люблю считать)

_____________
PHP: The Right Way
Бесплатное обучение Symfony2

Tox: 55BB67DE54B1CB14F8C37B4F3AED64E6A45922988D22F85EF75039751F26F05460664D978F5C