У меня в команде один программист таки таскал свою эргономичную клавиатуру каждый день из дома утром, и домой вечером, т.к. коммерческий директор отказался покупать ему в офис такую же.
Было время, были у меня дома и в офисе мониторы 27" FullHD. До этого всегда был 1 моник, максимум 19". Что я могу сказать, 27" гораздо удобнее, много помещается на экране, моно не открывать окна на весь экран. Думаю что 2 27" монитора были бы еще удобнее, при условии что есть место, где их разместить.
Весь трюк в Smarty не в том, чтобы уйти от PHP или, в более широком смысле, логики, в шаблонах, окончательно. От этого никуда не деться на самом деле. Но я, как разработчик, избавлен, от нечитаемого, лично для меня, PHP в шаблонах.
Так уж сложилось, что я, на уровне рефлексов, издавна, еще со времен Pascal, а потом и Clipper, привык к жестко структурированному коду. Смысл в этом был огромный, т.к. я писал бухгалтерские приложения, и количество кода, порой, доходило до 15 тысяч строк. Если в таком количестве кода не наводить дОлжный порядок, то развивать такой код становится затруднительно, даже если сам его писал от «А» до «Я». К слову сказать, несколько программ, написанных в 2004-2006 годах проработали без сбоев (кое-что и сегодня работает) вплоть до 2012 года, когда контора стала массово переходить на софт типа 1С.
И еще, PHP в шаблонах, не будучи структурированным, меня просто убивает. И да, я знаю, что многим другим программистам он там вполне комфортен. Я говорю только за себя.
Сам же Smarty компилирует шаблоны, превращая в самый обыкновенный PHP pазбавленный HTML/JS.
Т.е. Smarty — это дополнительный уровень абстракции. Таким образом имеется 2 уровня шаблонов. Первый — это абстракция, с которой я работаю как разработчик. Там прекрасно код Smarty отделен от остального HTML/JS, и позволяет гибко передавать данные и регулировать шаблонную логику, о которой контроллеру знать совершенно не обязательно. Smarty в шаблонах, на мой взгляд, куда как более читаем и лаконичен, органичен, я бы даже сказал. Второй уровень шаблонов — это фактический код, откомпилированный из первого, движком Smarty, и непосредственно исполняемый в системе.
И да, от условий и некоторой логики в шаблонах никуда не деться. Благо сейчас уже акценты бурно смещаются в сторону клиентской динамики, где море JS. Это совершенно отдельная песня. В моем случае, как я уже писал, где-то в этой ветке, индивидуальный JS так же шаблонизирован, что позволяет гибко вставлять куда надо управляющие конструкции. Получается своего рода мета-программирование, т.к. JS-код может гибко реагировать на некоторые условия, пришедшие как управляющий сигнал от контроллера.
Возвращаясь к логике в шаблонах — это другая логика, это логика шаблона. И к контроллеру она не имеет вообще никакого отношения. Поэтому, по моему глубочайшему убеждению, контроллеру совершенно не обязательно знать ту логику, которая касается исключительно шаблона.
Работал я недавно в связке с одним программистом, причем решения принимал я, в виду должностной инструкции и обязанностей, а он мне должен был помогать. Так вот, программист бурно не переносил вообще какую-либо логику в шаблонах, а, так же, инклюды, норовя вынести всю шаблонную логику в контроллер, там же подключая подшаблоны (порой с довольно сложной иерархией и зависимостями). В результате, открывая шаблон, я совершенно не мог понять, что там происходит. Откуда-то появились блоки с произвольным функционалом, никак не регламентированным самим шаблоном. В то же время код контроллера превратился в километры невнятных условий. Открывая такой контроллер я переставал понимать, чем он вообще занимается.
Например меню, которое касается только представления, генерилось у него в месте, совершенно никак логически не связанном с самим представлением, вплоть до вставки HTML-кусков в рамках контроллера. Это уже было слишком! Конечно эти безобразия я пресек на корню, по поводу чего было очень много стонов. Пресек категорически, т.к. время потраченное на поиски неочевидной логики и зависимостей я считаю напрасно потраченным.
Лично для меня Smarty куда как ближе к JavaScript, нежели к PHP, т.к. оба этих инструмента оперируют, как раз таки, в области представления. Говоря ближе, я подразумеваю именно область влияния.
Более того, вся иерархия подключаемых подшаблонов у меня лично регулируется из мастер-шаблона, что избавляет контроллер вообще от подобных, неуместных, на мой взгляд, забот. Т.е. контроллер у меня, как правило, предельно простой. Его задача — отработать бизнес-логику, отдать данные и управляющий сигнал. Что происходит дальше — его НЕ КАСАЕТСЯ!
Т.е. схема следующая:
1) Точка входа производит базовую инициализацию, типа названия приложения и ключевых констант, в основном это базовые пути, далее передает управление.
2) Ядро инициализирует приложение, гибко подключает, по необходимости, те или иные модули, в зависимости от настроек.
3) Роутер определяет какой контроллер должен отработать, после чего ядро вызывает его обернутым в функцию, таким образом контроллер изолирован от остального приложения, в том числе по части вывода на экран какого-либо мусора.
4) Контроллер, кроме прочего, возвращает параметр — конечный обработчик данных.
5) Далее ядро вызывает обработчик с данными, полученными от контроллера и общей конфигурацией приложения, в том числе со заданными всеми путями. И уже конечный результат формируется обработчиком.
*) А теперь представим, что контроллер сгенерил кучу HTML, в то время как он должен быть гибок и мочь сработать хоть в HTML, хоть в JSON, хоть куда еще…
В движок я зашил несколько библиотек, здорово облегчающих жизнь, например Smarty и DBSimple.
И да, тема скинов тоже замечательно регулируется тоже. Например на многих сайтах которые я делал на движке, на главной странице скин несколько отличается от оного на внутренних. Как Вы уже могли догадаться, контроллер вообще ничего об этом не знает. :)
Первейшим делом программист очень хорошо должен понимать что делает и какие последствия возникнут в результате тех или иных его действий. Т.е. процесс разработки должен быть прогнозируемым. Когда время ограничено, оптимальный путь — пользоваться тем, чем уже владеешь.
Неоднократно брался подобрать под себя фреймворк. Однако это довольно обширная область знаний, которая требует немалых затрат времени и усилий на освоение на дОлжном качестве, иначе не будет необходимого контроля над проектом. Когда ты программист-одиночка, то это может стать весьма нетривиальной задачей.
В результате я решил прекратить все эти метания, т.к. дело делать надо, а не метаться. К тому времени на голом PHP я программировал уже достаточно, чтобы собрать базовые грабли в непростом вопросе строительства веб-приложений.
До этого я много лет программировал бухгалтерские приложения на Clipper, а еще раньше это были поделки на Pascal 6.0 и 7.0, но это совершенно другая история.
Для меня одна из больных тем в фреймворках — это шаблонизация.
Не хочу порождать холиваров, это сугубо моё личное мнение, но лично я не выношу PHP-код замешанный внутри HTML. И, хотя, для PHP это изначальное и органичное поведение, у меня оно вызывает реакцию бурного отторжения. Достаточно давно я открыл для себя Smarty. Я искренне считаю, что он великолепен.
В своем «движе» я пошел путем полного разделения логики от представления. Т.е. контроллер и модель, буквально, ничего не знаю о представлении. Более того, легким движением руки ядро может переназначить обработчик представления, по необходимости.
Если в двух словах, то всю базовую работу делает ядро, тут я ничего нового не изобрел. А вот код контроллера-модели минимальный. Его задача — вернуть некий массив с параметрами — результатом своей работы.
Дальше, в зависимости от параметров, вызывается тот или иной обработчик выдачи. Одни и те же данные можно отдать хоть в шаблон, и это будет страница, хоть в конвертер JSON, и это будет уже, как правило, обработка AJAX-запроса.
В последней версии «движка» я пошел еще дальше. Текущий проект — богатое функционалом и гридами веб-приложение. Понадобился шаблонизиованный JS, во многом индивидуальный для каждой страницы.
Раньше я тупо вшивал это в <head>, либо выносил в публичный каталог /js/, но это оказалось неудобным. Потратив 10 минут времени я склонировал обработчик Smarty-шаблонов, пропатчил его, и теперь могу гибко обращаться к тому же адресу с одним дополнительным параметром, и страничка получит свой индивидуальный JS-код, отдельным файлом.
Файлы удобно лежат в логичной, продуманной и жесткой структуре, с жестким именованием (все равно неймспейсы к этому сейчас всех подводят уже). Все под рукой, все в ожидаемых и прогнозируемых местах.
ООП использую по минимуму, только там, где без него вовсе никак, либо в готовых библиотеках, тот же Smarty, например. Старая закалка в процедурном стиле сказывается, однако. Как я уже писал выше, надо делать дело, а процедурным инструментом я пользуюсь давно и владею, как мне кажется, неплохо, практически на уровне рефлексов. На ООП, к сожалению, рефлексов пока не выработалось.
Дядька сказал что напечатанная стена, показанная в ролике, в 3 раза прочнее обычного бетона. Там разные присадки, волокна. Плюс за счет пустот она довольно лёгкая и хорошо держит тепло.
Если в DOM что-либо менялось минуя jQuery, то кешированные в переменные объекты с селекторов придется тоже как-то обновлять. Это вообще болезненная тема и собственно само по себе кеширование тут имеет мало непосредственного отношения.
Особенно интересно было играть после патча сейва в хекс-редакторе. Паника у пришельцев весьма умиляла, когда их простреливали со снайперской точностью с другого конца карты.
Я тогда, будучи школьником, на паскале мастрячил, правда не игры совсем. Прям аж бурно вспомнил как 640КБ памяти очень быстро перестало хватать и как я учился пользовать через собственные типы данных и указатели память, доступную из защищенного ДОС-режима.
Я пользуюсь SciTE, подсветка имеется, и не спасает.
<a href="{$url}">{$url_txt}</a> <a href="<?=$url?>"><?=$url_txt?></a>вариант {$url_txt} гораздо более удобочитаем,
нежели <?=$url_txt?>
Ну и инклюды подшаблонов и блоков, т.к. часто удобнее некий относительно универсальный блок вынести и повторно использовать.
Так уж сложилось, что я, на уровне рефлексов, издавна, еще со времен Pascal, а потом и Clipper, привык к жестко структурированному коду. Смысл в этом был огромный, т.к. я писал бухгалтерские приложения, и количество кода, порой, доходило до 15 тысяч строк. Если в таком количестве кода не наводить дОлжный порядок, то развивать такой код становится затруднительно, даже если сам его писал от «А» до «Я». К слову сказать, несколько программ, написанных в 2004-2006 годах проработали без сбоев (кое-что и сегодня работает) вплоть до 2012 года, когда контора стала массово переходить на софт типа 1С.
И еще, PHP в шаблонах, не будучи структурированным, меня просто убивает. И да, я знаю, что многим другим программистам он там вполне комфортен. Я говорю только за себя.
Сам же Smarty компилирует шаблоны, превращая в самый обыкновенный PHP pазбавленный HTML/JS.
Т.е. Smarty — это дополнительный уровень абстракции. Таким образом имеется 2 уровня шаблонов. Первый — это абстракция, с которой я работаю как разработчик. Там прекрасно код Smarty отделен от остального HTML/JS, и позволяет гибко передавать данные и регулировать шаблонную логику, о которой контроллеру знать совершенно не обязательно. Smarty в шаблонах, на мой взгляд, куда как более читаем и лаконичен, органичен, я бы даже сказал. Второй уровень шаблонов — это фактический код, откомпилированный из первого, движком Smarty, и непосредственно исполняемый в системе.
И да, от условий и некоторой логики в шаблонах никуда не деться. Благо сейчас уже акценты бурно смещаются в сторону клиентской динамики, где море JS. Это совершенно отдельная песня. В моем случае, как я уже писал, где-то в этой ветке, индивидуальный JS так же шаблонизирован, что позволяет гибко вставлять куда надо управляющие конструкции. Получается своего рода мета-программирование, т.к. JS-код может гибко реагировать на некоторые условия, пришедшие как управляющий сигнал от контроллера.
Возвращаясь к логике в шаблонах — это другая логика, это логика шаблона. И к контроллеру она не имеет вообще никакого отношения. Поэтому, по моему глубочайшему убеждению, контроллеру совершенно не обязательно знать ту логику, которая касается исключительно шаблона.
Работал я недавно в связке с одним программистом, причем решения принимал я, в виду должностной инструкции и обязанностей, а он мне должен был помогать. Так вот, программист бурно не переносил вообще какую-либо логику в шаблонах, а, так же, инклюды, норовя вынести всю шаблонную логику в контроллер, там же подключая подшаблоны (порой с довольно сложной иерархией и зависимостями). В результате, открывая шаблон, я совершенно не мог понять, что там происходит. Откуда-то появились блоки с произвольным функционалом, никак не регламентированным самим шаблоном. В то же время код контроллера превратился в километры невнятных условий. Открывая такой контроллер я переставал понимать, чем он вообще занимается.
Например меню, которое касается только представления, генерилось у него в месте, совершенно никак логически не связанном с самим представлением, вплоть до вставки HTML-кусков в рамках контроллера. Это уже было слишком! Конечно эти безобразия я пресек на корню, по поводу чего было очень много стонов. Пресек категорически, т.к. время потраченное на поиски неочевидной логики и зависимостей я считаю напрасно потраченным.
Лично для меня Smarty куда как ближе к JavaScript, нежели к PHP, т.к. оба этих инструмента оперируют, как раз таки, в области представления. Говоря ближе, я подразумеваю именно область влияния.
Более того, вся иерархия подключаемых подшаблонов у меня лично регулируется из мастер-шаблона, что избавляет контроллер вообще от подобных, неуместных, на мой взгляд, забот. Т.е. контроллер у меня, как правило, предельно простой. Его задача — отработать бизнес-логику, отдать данные и управляющий сигнал. Что происходит дальше — его НЕ КАСАЕТСЯ!
Т.е. схема следующая:
1) Точка входа производит базовую инициализацию, типа названия приложения и ключевых констант, в основном это базовые пути, далее передает управление.
2) Ядро инициализирует приложение, гибко подключает, по необходимости, те или иные модули, в зависимости от настроек.
3) Роутер определяет какой контроллер должен отработать, после чего ядро вызывает его обернутым в функцию, таким образом контроллер изолирован от остального приложения, в том числе по части вывода на экран какого-либо мусора.
4) Контроллер, кроме прочего, возвращает параметр — конечный обработчик данных.
5) Далее ядро вызывает обработчик с данными, полученными от контроллера и общей конфигурацией приложения, в том числе со заданными всеми путями. И уже конечный результат формируется обработчиком.
*) А теперь представим, что контроллер сгенерил кучу HTML, в то время как он должен быть гибок и мочь сработать хоть в HTML, хоть в JSON, хоть куда еще…
В движок я зашил несколько библиотек, здорово облегчающих жизнь, например Smarty и DBSimple.
И да, тема скинов тоже замечательно регулируется тоже. Например на многих сайтах которые я делал на движке, на главной странице скин несколько отличается от оного на внутренних. Как Вы уже могли догадаться, контроллер вообще ничего об этом не знает. :)
Как говорится, сам себя не похвалишь…
Неоднократно брался подобрать под себя фреймворк. Однако это довольно обширная область знаний, которая требует немалых затрат времени и усилий на освоение на дОлжном качестве, иначе не будет необходимого контроля над проектом. Когда ты программист-одиночка, то это может стать весьма нетривиальной задачей.
В результате я решил прекратить все эти метания, т.к. дело делать надо, а не метаться. К тому времени на голом PHP я программировал уже достаточно, чтобы собрать базовые грабли в непростом вопросе строительства веб-приложений.
До этого я много лет программировал бухгалтерские приложения на Clipper, а еще раньше это были поделки на Pascal 6.0 и 7.0, но это совершенно другая история.
Для меня одна из больных тем в фреймворках — это шаблонизация.
Не хочу порождать холиваров, это сугубо моё личное мнение, но лично я не выношу PHP-код замешанный внутри HTML. И, хотя, для PHP это изначальное и органичное поведение, у меня оно вызывает реакцию бурного отторжения. Достаточно давно я открыл для себя Smarty. Я искренне считаю, что он великолепен.
В своем «движе» я пошел путем полного разделения логики от представления. Т.е. контроллер и модель, буквально, ничего не знаю о представлении. Более того, легким движением руки ядро может переназначить обработчик представления, по необходимости.
Если в двух словах, то всю базовую работу делает ядро, тут я ничего нового не изобрел. А вот код контроллера-модели минимальный. Его задача — вернуть некий массив с параметрами — результатом своей работы.
Дальше, в зависимости от параметров, вызывается тот или иной обработчик выдачи. Одни и те же данные можно отдать хоть в шаблон, и это будет страница, хоть в конвертер JSON, и это будет уже, как правило, обработка AJAX-запроса.
В последней версии «движка» я пошел еще дальше. Текущий проект — богатое функционалом и гридами веб-приложение. Понадобился шаблонизиованный JS, во многом индивидуальный для каждой страницы.
Раньше я тупо вшивал это в
<head>, либо выносил в публичный каталог /js/, но это оказалось неудобным. Потратив 10 минут времени я склонировал обработчик Smarty-шаблонов, пропатчил его, и теперь могу гибко обращаться к тому же адресу с одним дополнительным параметром, и страничка получит свой индивидуальный JS-код, отдельным файлом.Файлы удобно лежат в логичной, продуманной и жесткой структуре, с жестким именованием (все равно неймспейсы к этому сейчас всех подводят уже). Все под рукой, все в ожидаемых и прогнозируемых местах.
ООП использую по минимуму, только там, где без него вовсе никак, либо в готовых библиотеках, тот же Smarty, например. Старая закалка в процедурном стиле сказывается, однако. Как я уже писал выше, надо делать дело, а процедурным инструментом я пользуюсь давно и владею, как мне кажется, неплохо, практически на уровне рефлексов. На ООП, к сожалению, рефлексов пока не выработалось.
Вот такая вот лирика.
А недра не остынут, пока существует гравитация.
Интересно, когда на Луне тектонику обнаружат уже?
По моему это весьма скользкая дорожка с огромным соблазном у злоупотреблениям для умельцев.
Если в DOM что-либо менялось минуя jQuery, то кешированные в переменные объекты с селекторов придется тоже как-то обновлять. Это вообще болезненная тема и собственно само по себе кеширование тут имеет мало непосредственного отношения.
Перевод весьма качественный, на мой вкус.
Поностальжировал про времена ДОСа…
Я тогда, будучи школьником, на паскале мастрячил, правда не игры совсем. Прям аж бурно вспомнил как 640КБ памяти очень быстро перестало хватать и как я учился пользовать через собственные типы данных и указатели память, доступную из защищенного ДОС-режима.
Кто пробовал — поймет о чем я.
Ждем продолжения!