Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Я просто оставлю это здесь.
> Когда я заглянул в исходники MODx Evolution, меня едва ли не хватил удар. Рефакторить, рефакторить и рефакторить, как, наверное, сказал бы Ильич.
Открыв спойлер, у меня примерно такое же желание появилось… :) Для начала PSR, что по ссылке выше от IncorrecTSW, а далее по-Макконнеллу: Разнести на классы, разделить километровые методы на несколько более мелких и так далее. Плюс composer.json и прочие «ништячки».
Открыв спойлер, у меня примерно такое же желание появилось… :) Для начала PSR, что по ссылке выше от IncorrecTSW, а далее по-Макконнеллу: Разнести на классы, разделить километровые методы на несколько более мелких и так далее. Плюс composer.json и прочие «ништячки».
Когда-то давно-давно это было бомбой.
Чем ваше решение лучше, например, твига?
Чем ваше решение лучше, например, твига?
Давайте так, есть что-то лучше twig-а?
Все зависит от решаемых задач. Например, есть реализация mustache или Fenom, о котором писали на хабре.
Мое личное мнение: по-быстрому и по-простому отлично работают обычные php-шаблоны с минимальной обвязкой. В остальных случаях предпочитаю twig.
Мое личное мнение: по-быстрому и по-простому отлично работают обычные php-шаблоны с минимальной обвязкой. В остальных случаях предпочитаю twig.
Чем мне нравится twig — так это архитектурой, вы можете сделать из него что угодно. У вас есть возможность добавлять свои парсеры, обрабатывать AST шаблонов и т.д. Скажем можно красиво добавить поддержку jade в шаблоны твига или сделать то же что и у мусташ, но на базе twig-а.
В целом мне без разницы, у меня всеравно на сервере только api, а рендринг вынесен целиком и полностью на клиент.
В целом мне без разницы, у меня всеравно на сервере только api, а рендринг вынесен целиком и полностью на клиент.
Во-первых, проще. Зная систему шаблонизации MODx/Etomite, не придётся ломать голову над документацией. Во-вторых, оное не кушает несколько мегабайт во время работы, что позволяет использовать это решение на любом хостинге, даже на самом говённом. А исходник занимает 13 с копейками килобайт в одном файле.
Да, я помню одно из правил хорошего тона современного разработчика: везде и всегда использовать современные решения. А я вот недавно самостоятельно провёл бенчмарк PDO и mysqli. В результате теперь я не просто обхожу PDO стороной, а очень далёкими околицами, ибо эта срань жрёт ОЗУ раз эдак в шесть больше, чем mysqli, и раз в десять (!) больше, чем нативный php-mysql. А выигрыша по времени всё равно нету. К тому же я привык вместо использования всяких ORM-ов просто нормально писать запросы. Так что все эти рюшечки современных средств лично мне ни к чему. Ровно то же самое можно сказать и о любом другом сравнении современного модного трендового продукта и легковесного решения.
Да, я помню одно из правил хорошего тона современного разработчика: везде и всегда использовать современные решения. А я вот недавно самостоятельно провёл бенчмарк PDO и mysqli. В результате теперь я не просто обхожу PDO стороной, а очень далёкими околицами, ибо эта срань жрёт ОЗУ раз эдак в шесть больше, чем mysqli, и раз в десять (!) больше, чем нативный php-mysql. А выигрыша по времени всё равно нету. К тому же я привык вместо использования всяких ORM-ов просто нормально писать запросы. Так что все эти рюшечки современных средств лично мне ни к чему. Ровно то же самое можно сказать и о любом другом сравнении современного модного трендового продукта и легковесного решения.
С таким подходом вам дальше лендингов будет трудно уйти.
Ну вот здесь я поспорю. Мой подход просто весьма консервативен. Но он не означает, что я не стану использовать какие-либо решения, кушающие больше ресурсов, чем нативный HTML/CSS/PHP/MySQL. Каждой задаче — своё решение. Другой вопрос, что, скажем, использовать в высоконагруженном проекте PDO я бы не стал, а вот mysqli — без проблем. Вот, собственно, и вся суть подхода.
В разрабатываемой мною CMS в качестве шаблонизации используется как раз QuadBraces. В качестве расширения для работы с БД — php-mysqli. Результат — очень гибкая и многофункциональная CMS со средним временем отработки 15-20 миллисекунд и расходом ОЗУ не более 1,5 мегабайт (с дополнительными модулями). По экономии ресурсов «делает» даже мой любимый MODx Evolution (про Revo с его xPDO промолчу, ладушки). На такой CMS можно делать, мягко говоря, далеко не только лендинги.
Чем больше я смотрю на современные средства разработки, тем больше убеждаюсь, что оные — для ленивых. А самый удивительный парадокс заключается в том, что в сущности разницы по времени разработки никакой. А вот ресурсоёмкость в случае с консервативным подходом значительно меньше. В принципе оно объяснимо, ведь сейчас компьютеры большие и мощные. Вот только шансов, что упадёт, у «консервативной» системы куда меньше, чем у «трендовой».
В разрабатываемой мною CMS в качестве шаблонизации используется как раз QuadBraces. В качестве расширения для работы с БД — php-mysqli. Результат — очень гибкая и многофункциональная CMS со средним временем отработки 15-20 миллисекунд и расходом ОЗУ не более 1,5 мегабайт (с дополнительными модулями). По экономии ресурсов «делает» даже мой любимый MODx Evolution (про Revo с его xPDO промолчу, ладушки). На такой CMS можно делать, мягко говоря, далеко не только лендинги.
Чем больше я смотрю на современные средства разработки, тем больше убеждаюсь, что оные — для ленивых. А самый удивительный парадокс заключается в том, что в сущности разницы по времени разработки никакой. А вот ресурсоёмкость в случае с консервативным подходом значительно меньше. В принципе оно объяснимо, ведь сейчас компьютеры большие и мощные. Вот только шансов, что упадёт, у «консервативной» системы куда меньше, чем у «трендовой».
использовать в высоконагруженном проекте PDO я бы не стал, а вот mysqli — без проблем
Ну да, давайте будем экономить на спичках. Вы же понимаете что сейчас проще докупить пару серверов чем оплачивать работу программиста что бы тот оптимизировал все до потери сознания?
Я вообще не понимаю почему вы пишите на php при таком подходе, писали бы на python, где есть fastcgi настоящий или вообще на java, где нет расходов на бутстрапинг приложения ит.д. Ну или хотя бы reactphp, при наличии mysqli и его асинхронных запросов а так же корутин профит будет гораздо больше. Скажем у меня есть pet-project на Symfony2+Doctrine2, пожалуй одна из самых прожорливых комбинаций. Так вот, вместе с php-pm у меня в среднем время ответа выходит 50ms. И это на php5.6, на php7 все станет еще лучше. Подобные извращения полезны когда для нас уменьшение времени обработки запроса на 10ms это существенно. Но таких проектов меньше 0.1% от общей массы.
Чем больше я смотрю на современные средства разработки, тем больше убеждаюсь, что оные — для ленивых.
Не для ленивых, а для тех кто ценит свое время и деньги клиента.
А самый удивительный парадокс заключается в том, что в сущности разницы по времени разработки никакой.
Да, по времени разработки разница будет минимальна. А вот поддерживать эту систему выйдет сильно дороже, рефакторить такую систему будет дороже, добавлять функционал — дороже. А если у нас еще будет сложная бизнес логика мы можем просто заплакать. В принципе можно вкатит CQRS и под копотом делать любую сатану которую вы пожелаете, и тогда будет вроде бы и норм, но что-то мне подсказывает что это не для вас.
ну и да, если мы говорим о системах для генерации лэндингов и т.д проще просто поставить сверху варниш какой.
Да, вселенная оптимизации сайта под дешевые хостинги и бережливых клиентов существует где-то рядом. Быстро забывается и отсутствие ssh, и пляски с загрузками мегабайтных архивов с кодом через панель управления, поскольку ftp сутками прокачивает тонну мелких файлов.
Это очень, не побоюсь этого слова, нишевая разработка с другими подходами.
Это очень, не побоюсь этого слова, нишевая разработка с другими подходами.
Ну, что ж, можно ждать тыщу лет клиента с хорошим проектом. Если, конечно, есть на что кушать и оплачивать квартиру. А можно не брезговать и «нишевыми» заказами (на минуточку не менее 80% владельцев сайтов рунета) и иметь хотя бы маленький доход от оных. Даже в «кризис». Не знаю, как Вы, а я свой выбор сделал ;)
Под дешёвыми хостингами в данном случае понимается всё под определением «виртуальный хостинг».
Под дешёвыми хостингами в данном случае понимается всё под определением «виртуальный хостинг».
ну да, если ждать. А можно не ждать а искать самому. Вы удивитесь, но клиентов с такими вот «нишевыми» вещами становится все меньше и меньше а проектов в рунете интересных прибавляется, даже в период кризиса. Позитивные тенденции вроде psr-стандартов, composer и т.д. уже потихоньку переходят и в эту нишу, хостинги все больше и большей ориентируются на клиента, а оттуда и ssh и прочие плюшки вроде последних версий пыха или возможность использовать nodejs и т.д… Да и VDS за 5 баксов не сложно нынче купить, и многие уходят в эту сторону, так как экономия двух баксов и кастыли которые из-за этой экономии приходится впиливать — это так себе экономия.
Любая работа может быть интересной, это вопрос личного восприятия. Я сейчас с приятной ностальгией вспоминаю то, о чем говорит XanderBass.
А что касается VDS за 5 баксов — большинство по качеству (производительности) не далеко ушли от шареда, просто повышают ЧСВ за счет роста ответственности. И приходится так же заниматься оптимизацией, придумывать способы избавиться от лишнего балласта, писать свои узкоспециализированные решения вместо использования популярных библиотек-комбайнов.
Но вот за стандарты я готов горой стоять. И за тесты. Ничто не мешает применять современные техники даже в олдскульном стиле. Тем более, что трудозатраты на написание composer.json минимальные, а тесты еще тыщу раз сыграют на руку.
А что касается VDS за 5 баксов — большинство по качеству (производительности) не далеко ушли от шареда, просто повышают ЧСВ за счет роста ответственности. И приходится так же заниматься оптимизацией, придумывать способы избавиться от лишнего балласта, писать свои узкоспециализированные решения вместо использования популярных библиотек-комбайнов.
Но вот за стандарты я готов горой стоять. И за тесты. Ничто не мешает применять современные техники даже в олдскульном стиле. Тем более, что трудозатраты на написание composer.json минимальные, а тесты еще тыщу раз сыграют на руку.
> Вы же понимаете что сейчас проще докупить пару серверов
> чем оплачивать работу программиста что бы тот оптимизировал все до потери сознания?
Для заказчика проще. А мне вот, как разработчику, совесть не позволит делать прожорливые, толстые проекты, по функциональности не соответствующие своей прожорливости. Это во-первых. Во-вторых, Вы, видимо, не сталкивались в своей практике с заказчиками, которые вообще ничего, кроме виртуальных хостингов не признают. А есть (о, ужас!!!) такие, которые признают только дешёвые хостинги. А проектов на виртуальных хостингах — открою Вам глаза — более 80% от общей массы по меньшей мере в рунете. Менее 20% владельцев сайтов в сети имеют свои выделенные серверы. Потому что держать ради одного среднестатистического интернет-магазина сервер и штат программистов, мягко говоря, накладно. А среднестатистическому проекту, если оный грамотно разработан, вполне хватит в месяц часа CPU и стандартных 64-128 Мб ОЗУ. Это уже из личного опыта поддержки трёх интернет-магазинов.
> А вот поддерживать эту систему выйдет сильно дороже,
> рефакторить такую систему будет дороже, добавлять функционал — дороже.
Очень спорное утверждение. Всё зависит от того, кто будет поддерживать разработанную систему — это раз. Обычно поддержкой занимается исходный разработчик, если речь о больших проектах. Во-вторых, даже на таких вот решениях можно сделать гибкую архитектуру. Всё зависит от мастерства разработчика. Ещё раз повторю одну крылатую фразу:
— Настоящий художник может нарисовать шедевр даже гвоздём на стекле. Всё зависит от уровня мастерства.
А то, что изначально написано грамотно, оптимизировать вряд ли потребуется.
> чем оплачивать работу программиста что бы тот оптимизировал все до потери сознания?
Для заказчика проще. А мне вот, как разработчику, совесть не позволит делать прожорливые, толстые проекты, по функциональности не соответствующие своей прожорливости. Это во-первых. Во-вторых, Вы, видимо, не сталкивались в своей практике с заказчиками, которые вообще ничего, кроме виртуальных хостингов не признают. А есть (о, ужас!!!) такие, которые признают только дешёвые хостинги. А проектов на виртуальных хостингах — открою Вам глаза — более 80% от общей массы по меньшей мере в рунете. Менее 20% владельцев сайтов в сети имеют свои выделенные серверы. Потому что держать ради одного среднестатистического интернет-магазина сервер и штат программистов, мягко говоря, накладно. А среднестатистическому проекту, если оный грамотно разработан, вполне хватит в месяц часа CPU и стандартных 64-128 Мб ОЗУ. Это уже из личного опыта поддержки трёх интернет-магазинов.
> А вот поддерживать эту систему выйдет сильно дороже,
> рефакторить такую систему будет дороже, добавлять функционал — дороже.
Очень спорное утверждение. Всё зависит от того, кто будет поддерживать разработанную систему — это раз. Обычно поддержкой занимается исходный разработчик, если речь о больших проектах. Во-вторых, даже на таких вот решениях можно сделать гибкую архитектуру. Всё зависит от мастерства разработчика. Ещё раз повторю одну крылатую фразу:
— Настоящий художник может нарисовать шедевр даже гвоздём на стекле. Всё зависит от уровня мастерства.
А то, что изначально написано грамотно, оптимизировать вряд ли потребуется.
А то, что изначально написано грамотно, оптимизировать вряд ли потребуется.
premature optimization короче, я вас понял. А вы нагрузочные тесты может еще пишите когда выдумываете такие подходы? Что-то сомневаюсь.
Вы, видимо, не сталкивались в своей практике с заказчиками, которые вообще ничего, кроме виртуальных хостингов не признают.
Я не работаю с такими клиентами, и обычно я навязываю что должен использовать клиент, ибо как правило он не шарит. Да и клиенту это выгодно, ибо в случае когда я контролирую куда кто будет деплоиться, я могу воспользоваться штуками типа ansible и сократить издержки на рутину, вроде деплоймента.
А проектов на виртуальных хостингах — открою Вам глаза — более 80% от общей массы по меньшей мере в рунете.
Как бы так сказать, меня не интересуют эти 80%. Вот совсем не интересуют.
— Настоящий художник может нарисовать шедевр даже гвоздём на стекле. Всё зависит от уровня мастерства.
Вот только пользователю вашей системы или даже клиенту глубоко плевать что там внутри, шедевр или кусок гуано. Им главное что бы это работало, приносило деньги и позволяло развиваться дальше. Возможно по этому бэкэндеры так много пьют.
Словом мне кажется мы о разных масштабах говорим. А системы для реализации лэндингов и корп сайтов — так их можно хоть как делать, и вместо того что бы изобретать велосипеды можно просто нормально настроить http кэш и жахнуть сверху реверс прокси. Ну или вообще использовать генераторы статических сайтов.
> premature optimization короче, я вас понял. А вы нагрузочные тесты может еще пишите
> когда выдумываете такие подходы? Что-то сомневаюсь.
Сомневайтесь, Ваше право. Вот только я всегда всё тестирую — каждую мелочь. И, да, premature optimization и просто грамотная разработка — это разные вещи. Если я изначально использую грамотный алгоритм, отшлифованный до мелочей — это второе, а не первое. И в случае с изначально грамотным проектированием оптимизировать обычно ничего не требуется. Минимум кода, максимум эффективности.
> Я не работаю с такими клиентами, и обычно я навязываю что должен использовать клиент,
> ибо как правило он не шарит.
Вот на этом месте, собственно, можно завершить нашу беседу, ибо у нас совершенно разный подход к клиенту. У меня подход ориентирован на самого клиента, а не на моё `авторитетное` мнение. Если клиент беден, как церковная мышь, я всё равно беру заказ и делаю его на совесть, даже если мне потребуется раскурить для этого десятки мануалов. У Вас же всё опирается на Вашу точку зрения, как лучше. В этом, собственно, вся соль нашей дискуссии.
> когда выдумываете такие подходы? Что-то сомневаюсь.
Сомневайтесь, Ваше право. Вот только я всегда всё тестирую — каждую мелочь. И, да, premature optimization и просто грамотная разработка — это разные вещи. Если я изначально использую грамотный алгоритм, отшлифованный до мелочей — это второе, а не первое. И в случае с изначально грамотным проектированием оптимизировать обычно ничего не требуется. Минимум кода, максимум эффективности.
> Я не работаю с такими клиентами, и обычно я навязываю что должен использовать клиент,
> ибо как правило он не шарит.
Вот на этом месте, собственно, можно завершить нашу беседу, ибо у нас совершенно разный подход к клиенту. У меня подход ориентирован на самого клиента, а не на моё `авторитетное` мнение. Если клиент беден, как церковная мышь, я всё равно беру заказ и делаю его на совесть, даже если мне потребуется раскурить для этого десятки мануалов. У Вас же всё опирается на Вашу точку зрения, как лучше. В этом, собственно, вся соль нашей дискуссии.
А давно пхп можно употреблять в контексте не прожорливого?
Скажите пожалуйста, чем вот это
проще и понятнее, чем
И еще расскажите, как на этом чудо-шаблонизаторе сделать, например, простой цикл for
[!my.cool.snippet:empty=`пустонафик` &argument=`foobar`!]
проще и понятнее, чем
{% if !my_cool_snippet(argument='foobar') %}
пустонафик
{% endif %}
И еще расскажите, как на этом чудо-шаблонизаторе сделать, например, простой цикл for
А никак. И переменную не присвоить и еще много чего не сделать. Это, по сути, такой продвинутый str_replace(placeholders, values) и ничего больше.
Именно поэтому я интегрировал в MODX Revolution нормальный шаблонизатор Fenom, а тут, выходит, обратный процесс.
Именно поэтому я интегрировал в MODX Revolution нормальный шаблонизатор Fenom, а тут, выходит, обратный процесс.
Странный, какой-то, у вас вопрос. MODX мне нравится — вот и работаю с ним.
Пишу дополнения, которые расширяют его функционал и не меняют при этом ядро системы. Никаких «перелопачиваний» или хаков нет, везде используются штатные возможности системы.
И да, советую еще вот эту заметку, а то неправильное написание названия режет глаз.
Пишу дополнения, которые расширяют его функционал и не меняют при этом ядро системы. Никаких «перелопачиваний» или хаков нет, везде используются штатные возможности системы.
И да, советую еще вот эту заметку, а то неправильное написание названия режет глаз.
Я поработал с MODX достаточно, чтобы понять — такое я не запилю =)
Серьёзно, создавать свою CMS, развивать и поддерживать — это же адский труд, зачем? И чем она будет лучше? Тем более, что меня в Revolution почти всё устраивает, а что нет — расширяю дополнениями или отправляю в ядро pull-requests. В итоге сформировалась приличная библиотека готовых актуальных решений, которые я могу использовать почти на любом проекте.
А магазин дополнений, и даже свой хостинг для MODX, мы уже сделали, так что и здесь вопросов нет.
Серьёзно, создавать свою CMS, развивать и поддерживать — это же адский труд, зачем? И чем она будет лучше? Тем более, что меня в Revolution почти всё устраивает, а что нет — расширяю дополнениями или отправляю в ядро pull-requests. В итоге сформировалась приличная библиотека готовых актуальных решений, которые я могу использовать почти на любом проекте.
А магазин дополнений, и даже свой хостинг для MODX, мы уже сделали, так что и здесь вопросов нет.
Минуточку. Вот в моём случае выполнится код, заложенный в сниппете (а там может быть очень много кода). А что в результате выполнится у Вас? Ну да ладно, Вам виднее.
Лично мне, как и любому человеку, не знакомому с Twig, но знакомому с MODx, будет проще и понятнее. Послушайте, никто не говорит, что это супер-бомба, призванная похоронить продвинутые трендовые шаблонизаторы. Эта штуковина создана только с одной целью (цитирую):
для того, чтобы не заколачивать микроскопом гвозди, то есть не ставить для лендингов MODx, но иметь возможность использовать эту шаблонизацию
Кстати, насчёт переменных, циклов и прочего. По моему глубокому убеждению логика сложнее if-then-else — это уже программирование. IMHO, программировать в шаблонизаторах — это примерно то же самое, что раскатывать асфальт велосипедом.
Лично мне, как и любому человеку, не знакомому с Twig, но знакомому с MODx, будет проще и понятнее. Послушайте, никто не говорит, что это супер-бомба, призванная похоронить продвинутые трендовые шаблонизаторы. Эта штуковина создана только с одной целью (цитирую):
для того, чтобы не заколачивать микроскопом гвозди, то есть не ставить для лендингов MODx, но иметь возможность использовать эту шаблонизацию
Кстати, насчёт переменных, циклов и прочего. По моему глубокому убеждению логика сложнее if-then-else — это уже программирование. IMHO, программировать в шаблонизаторах — это примерно то же самое, что раскатывать асфальт велосипедом.
Теперь, например, так:
В самом чанке допустимо использовать внутренний плейсхолдер [+iterator+], поддерживающий в свою очередь расширения.
{{item-chunk:for=`6`:splitter=`<br />`}}
В самом чанке допустимо использовать внутренний плейсхолдер [+iterator+], поддерживающий в свою очередь расширения.
Да пожалуйста =)
На лендинге нужно вывести портфолио из нескольких проектов. Периодически проекты добавляются или убираются. Вёрстка каждого элемента одна и та же. Ну, разве что меняется парочка классов. Брать только из-за портфолио MODx — всё то же заколачивание гвоздей экскаватором. А чистый HTML поддеживать — адский трудЪ. Поверьте, я не на словах знаю, о чём говорю, у меня есть парочка таких проектов на поддержке. Дык вот берём этот шаблонизатор и пишем чанк (назовём его item) с вёрсткой одного элемента, допустим так:
Разумеется, на практике будет много сложнее, чем эти несколько строк. Далее, дабы потом не копаться, вынесем элементы портфолио в отдельный чанк (назовём его items), где тупо их списочком, списочком:
Соответственно, в сам лендинг мы тупо вставляем чанк {{items}}. Итого убили двух зайцев: не потребовалось ставить MODx и сделали легко поддерживаемую систему. Для того, чтобы добавить, отредактировать или убрать элемент, достаточно будет править содержимое чанка items.
На лендинге нужно вывести портфолио из нескольких проектов. Периодически проекты добавляются или убираются. Вёрстка каждого элемента одна и та же. Ну, разве что меняется парочка классов. Брать только из-за портфолио MODx — всё то же заколачивание гвоздей экскаватором. А чистый HTML поддеживать — адский трудЪ. Поверьте, я не на словах знаю, о чём говорю, у меня есть парочка таких проектов на поддержке. Дык вот берём этот шаблонизатор и пишем чанк (назовём его item) с вёрсткой одного элемента, допустим так:
<div class="item" id="item-[+item-id+]">
<h2>[+item-title+]</h2>
<img src="/images/[+item-id+]/1.jpg" />
<p>[+item-description+]</p>
<div class="galery-wrapper">
<img src="/images/[+item-id+]/1.jpg" />
<img src="/images/[+item-id+]/2.jpg" />
<img src="/images/[+item-id+]/3.jpg" />
<img src="/images/[+item-id+]/4.jpg" />
<img src="/images/[+item-id+]/5.jpg" />
</div>
</div>
Разумеется, на практике будет много сложнее, чем эти несколько строк. Далее, дабы потом не копаться, вынесем элементы портфолио в отдельный чанк (назовём его items), где тупо их списочком, списочком:
{{item &item-id=`1` &item-title=`Крутой проект №1` &item-description=`Наш первый крутой проект`}}
{{item &item-id=`2` &item-title=`Крутой проект №2` &item-description=`Наш второй крутой проект`}}
{{item &item-id=`3` &item-title=`Крутой проект №3` &item-description=`Наш третий крутой проект`}}
{{item &item-id=`4` &item-title=`Крутой проект №4` &item-description=`Наш четвёртый крутой проект`}}
{{item &item-id=`5` &item-title=`Крутой проект №5` &item-description=`Наш пятый крутой проект`}}
Соответственно, в сам лендинг мы тупо вставляем чанк {{items}}. Итого убили двух зайцев: не потребовалось ставить MODx и сделали легко поддерживаемую систему. Для того, чтобы добавить, отредактировать или убрать элемент, достаточно будет править содержимое чанка items.
А что бы так:
Причем если хочется модульности можно все так же разбить на миксины/виджеты. Неужели вам нравится такой подход?
{% for work in portfolio %}
<div class="item">
<h2>{{work.title}}</h2>
<img src="{{work.thumb.src}}" />
<p>{{ work.description }}</p>
<div class="galery-w
rapper">
{% for image in work.images %}
<img src="{{image.src}}" alt="{{image.alt}}" />
{% endfor %}
</div>
</div>
{% endfor %}
Причем если хочется модульности можно все так же разбить на миксины/виджеты. Неужели вам нравится такой подход?
Следите за коммитами на гите. Я добавил функционал, позволяющий проходиться циклом по элементам массива data парсера, являющимися массивами. То есть теперь для вывода портфолио можно добавить в массив data парсера элемент с ключом, скажем, items и вывести портфолио вот так
Если каждый элемент массива, являясь в свою очередь массивом будет содержать, скажем, элементы с ключами id, title, desc, то итератор (в промежуточной стадии) выведет следующее:
Замечу при этом, что парсер по прежнему кушает совсем немного =)
И спасибо за идею ;)
{!items &chunk=`item`!}
Если каждый элемент массива, являясь в свою очередь массивом будет содержать, скажем, элементы с ключами id, title, desc, то итератор (в промежуточной стадии) выведет следующее:
{{item &id=`id_элемента_1` &title=`title_элемента_1` &desc=`desc_элемента_1`}}
{{item &id=`id_элемента_2` &title=`title_элемента_2` &desc=`desc_элемента_2`}}
{{item &id=`id_элемента_3` &title=`title_элемента_3` &desc=`desc_элемента_3`}}
{{item &id=`id_элемента_4` &title=`title_элемента_4` &desc=`desc_элемента_4`}}
Замечу при этом, что парсер по прежнему кушает совсем немного =)
И спасибо за идею ;)
Ну а в нормальном шаблонизаторе было бы что-то вроде:
и шаблон item.tpl:
При этом можно использовать проверку на пустые или несуществующие переменные, фильтры, кэширование и еще много чего. Не удивлюсь, если в итоге шаблонизатор будет работать быстрее, чем свой, вроде бы более простой, парсер.
Ваш способ, конечно, имеет право на жизнь, но лично мне использование синтаксиса MODX вне этой системы непонятно.
Для примера — вот простейший мини-движок, написанный в обучающих целях, который подходит для разных там визиток и прочей простоты. В нём я постарался воплотить принципы работы MODX, но в более современной обёртке.
{foreach $items as $item}
{include 'item.tpl' item=$item}
{/foreach}
и шаблон item.tpl:
<div class="item" id="item-{$item.id}">
<h2>{$item.title}</h2>
<img src="/images{$item.id}/1.jpg" />
<p>{$item.description}</p>
{if $item.images}
<div class="galery-wrapper">
{foreach $item.images as $image}
<img src="/images/{$item.id}/{$image.id}.jpg" />
{/foreach}
</div>
{/if}
</div>
При этом можно использовать проверку на пустые или несуществующие переменные, фильтры, кэширование и еще много чего. Не удивлюсь, если в итоге шаблонизатор будет работать быстрее, чем свой, вроде бы более простой, парсер.
Ваш способ, конечно, имеет право на жизнь, но лично мне использование синтаксиса MODX вне этой системы непонятно.
Для примера — вот простейший мини-движок, написанный в обучающих целях, который подходит для разных там визиток и прочей простоты. В нём я постарался воплотить принципы работы MODX, но в более современной обёртке.
Мне еще нравится вариант с макросами для большей гибкости.
{# work.html.twig #}
{% macro small_preview(work) %}
<div class="portfolio-item portfolio-item--small">
<h2>{{work.title}}</h2>
<img src="{{work.thumb.src}}" />
<p>{{ work.description }}</p>
<div class="galery-w
rapper">
{% for image in work.images %}
<img src="{{image.src}}" alt="{{image.alt}}" />
{% endfor %}
</div>
</div>
{% endmarco %}
{# portfolio.html.twig #}
{% import 'work.html.twig' as work %}
{% for item in portfolio %}
{{ work.small_preview(item) }}
{% endfor %}
Если что — я не вам писал о нормальном шаблонизаторе.
Мы оба пишем автору топика об одном и том, только я на Fenom, а вы на Twig.
Мы оба пишем автору топика об одном и том, только я на Fenom, а вы на Twig.
Я заметил, поправил. Просто вариантов как это организовать столько, что вообще не понятно зачем людям свои велосипеды.
Можно и обычный массив. Однако, если учесть, что в чанке items каждая строка — это элемент, можно создать простой скрипт, который будет редактировать чанк items. И таким образом совершенно без использования СУБД мы можем реализовать простейшую панель управления для заказчика. Если включить фантазию, можно извернуться и вообще сделать своеобразную NoSQL-CMS.
Если включить фантазию, можно извернуться и вообще сделать своеобразную NoSQL-CMS.
Был у меня такой проектик, где страницы составлялись из блоков по аналогии с sir-trevor, а блоки сами парсились из шаблонов. Вышло довольно удобно, особенно для маркетологов с их желанием иметь возможность редактировать все и вся и при этом без возможности поломать верстку. Вместо html — markdown урезанный и чуть допиленный под нужды маркетологов (a/b тестирование). Как по мне для лэндингов, портфолио и т.д. самое то, с учетом того что все это еще и собиралось в html.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QuadBraces — по мотивам парсера MODx