Для разработчиков
Кешируем mFilter2
Как кол-во товаров на сайте переваливает какую-то границу, то mFilter2 начинает жестко тупить. Переодически мне приходиться бороться с этой проблемой. В итоге изучения mFilter2 выработал пару решений.
[miniShop2 4.0.0-beta] - Разбор нововведений. Небольшие изменения в контроллерах
В серии коротких заметок расскажу и детально покажу что нового мы сделали для Вас в новой версии miniShop2 Для MODX2
На очереди информация для разработчиков, касательно окончательного положения контроллеров.
На очереди информация для разработчиков, касательно окончательного положения контроллеров.
[miniShop2 4.0.0-beta] - Разбор нововведений. Гибкая настройка статусов
В серии коротких заметок расскажу и детально покажу что нового мы сделали для Вас в новой версии miniShop2 Для MODX2
На очереди обновление связанное со статусами заказов.
На очереди обновление связанное со статусами заказов.
[miniShop2 4.0.0-beta] - Разбор нововведений. Новый заказ из Админки
Систематизация, переиспользование и редактирование форм.
Приветствую! Я открыл для себя ещё один вариант использования компонента MIGX и хочу поделиться им с сообществом. Скорее всего, кто-то до меня так делал, но либо не делился, либо я не нашёл.
Для чего это нужно? На сайтах как правило есть несколько форм: обратная связь, подписка, отзывы и.т.д. Иногда формы эти содержат идентичный набор полей, но выглядят по-разному и располагаются на разных страницах. А ещё они могут отправляться на разные почты или наоборот все на одну. В общем, так или иначе это приводит к полному или частичному дублированию вызовов и к тому, что в случае необходимости внесения изменений, нужно править несколько файлов. Вот я и разработал несложную систему для упрощения управления формами.
Для чего это нужно? На сайтах как правило есть несколько форм: обратная связь, подписка, отзывы и.т.д. Иногда формы эти содержат идентичный набор полей, но выглядят по-разному и располагаются на разных страницах. А ещё они могут отправляться на разные почты или наоборот все на одну. В общем, так или иначе это приводит к полному или частичному дублированию вызовов и к тому, что в случае необходимости внесения изменений, нужно править несколько файлов. Вот я и разработал несложную систему для упрощения управления формами.
[ModExtra3] Заготовка для создания компонентов для MODX3
Одна из проблем развития экосистемы MODX3 на текущий день — не очень большой объем доступной информации, инструкций. Официальный сайт только недавно начал выпускать справочные пособия на тему разработки MODX3.
Мне в свое время очень помогла в понимании работы компонентов, подготовленная @Василий Наумкин заготовка для создания компонентов modExtra. Я решил поднять это знамя и донести его до MODX3
Представляю вашему вниманию ModExtra3. Заготовка для создания компонентов и справочное пособие по MODX3.
Мне в свое время очень помогла в понимании работы компонентов, подготовленная @Василий Наумкин заготовка для создания компонентов modExtra. Я решил поднять это знамя и донести его до MODX3
Представляю вашему вниманию ModExtra3. Заготовка для создания компонентов и справочное пособие по MODX3.
pdoParser против modParser
Третьего дня Сергей Шлоков провёл новый тест скорости работы парсера MODX и шаблонизаторов Fenom и Smarty.
До Smarty мне дела нет, но с итоговыми выводами, что никакой разницы в скорости между синтаксисом MODX и Fenom не видно, я категорически не согласен.
Итак, что нужно прояснить. У оригинального парсера MODX modParser есть две, на мой взгляд, фундаментальные проблемы:
Во-первых, каждый тег при разборе превращается в PHP объект modTag и в нём запускается метод process. То есть, если в чанке указан просто [[+id]], то MODX вместо обычной замены его через str_replace будет создавать новый объект и парсить.
Во-вторых, из-за своей рекурсивной природы, MODX выполняет все условия в чанках. Он просто не знает, во что могут превратиться эти условия на пятой, например, итерации. Причём делает он это изнутри наружу.
То есть, если вы прячете какой-то кусок оформления для вывода только нужным пользователям за условиями в чанке — именно этот кусок и будет первым делом разобран, а потом MODX решит, нужно ли его выводить, когда проверит условие с юзером. Народ придумывает разные костыли для обхода этого момента, чтобы парсить только нужное, типа [[![[+user:is=`admin`:then=`auth`:else=`guest`]]]].
До Smarty мне дела нет, но с итоговыми выводами, что никакой разницы в скорости между синтаксисом MODX и Fenom не видно, я категорически не согласен.
Итак, что нужно прояснить. У оригинального парсера MODX modParser есть две, на мой взгляд, фундаментальные проблемы:
Во-первых, каждый тег при разборе превращается в PHP объект modTag и в нём запускается метод process. То есть, если в чанке указан просто [[+id]], то MODX вместо обычной замены его через str_replace будет создавать новый объект и парсить.
Во-вторых, из-за своей рекурсивной природы, MODX выполняет все условия в чанках. Он просто не знает, во что могут превратиться эти условия на пятой, например, итерации. Причём делает он это изнутри наружу.
То есть, если вы прячете какой-то кусок оформления для вывода только нужным пользователям за условиями в чанке — именно этот кусок и будет первым делом разобран, а потом MODX решит, нужно ли его выводить, когда проверит условие с юзером. Народ придумывает разные костыли для обхода этого момента, чтобы парсить только нужное, типа [[![[+user:is=`admin`:then=`auth`:else=`guest`]]]].
Сравнение шаблонизаторов MODX, Fenom и Smarty
В очередной раз прочитав утверждение, что Fenom быстрее стандартного парсера, решил провести указанный в документации pdoTools тест, чтобы расставить все точки над и. Но решил сделать это не отдельными скриптами, как в документации, а практичнее — через сниппет, который будет вызыватся на странице. Плюс добавил для сравнения шаблонизатор Smarty из ZoomX. Так вот, у меня таки есть шо вам сказать.
Кэширование элементов в ZoomX
ZoomX постепенно начинает набирать популярность. В связи с чем возникает ряд вопросов. Один из которых — кэширование элементов в шаблонизаторе Smarty. В принципе, по документации не сложно разобраться. Но, конечно, модыксерам хотелось бы работать так, как они привыкли. В этом плане Fenom из pdoTools реализован именно по этому принципу — для запрета кэширования в названии элемента указывается восклицательный знак. Всё привычно. Но работает не всегда.
Использование MODX вне MODX3
Перевод заметки Using MODX Outside of MODX3
В одной из статей было рассмотрено создание экземпляра объекта $modx в эпоху до MODX3. В этой статье мы рассмотрим использование MODX вне MODX Revolution 3. Большая часть кода такая же, как и в предыдущей статье (прим. переводчика: предыдущая статья не переведена, так как немного не актуальна в рамках перехода на модх3). Основное отличие состоит в том, что MODX Revolution 3 широко использует пространства имен и имеет автозагрузчик для загрузки классов.
В одной из статей было рассмотрено создание экземпляра объекта $modx в эпоху до MODX3. В этой статье мы рассмотрим использование MODX вне MODX Revolution 3. Большая часть кода такая же, как и в предыдущей статье (прим. переводчика: предыдущая статья не переведена, так как немного не актуальна в рамках перехода на модх3). Основное отличие состоит в том, что MODX Revolution 3 широко использует пространства имен и имеет автозагрузчик для загрузки классов.