Идея: выносить весь код из сниппетов, плагинов, контроллеров в zoomx в классы

Подумал тут, что сниппеты — довольно костыльная штука. А ещё код может потребоваться переиспользовать, как в плагинах, так и в сниппетах. Выносить в сниппет функцию и вызывать через runSnippet? Как по мне, ещё больший костыль. В общем такая идея: в папке elements/classes хранить различные классы, нужные для функционала сайта. Создать один сниппет (допустим run), передавать ему какой метод из какого класса вызвать и параметры.

Я не работал с фреймворками и другими cms, не знаю, как там устроено. Напишите, как вам идея, если не очень, предложите своё решение) А ещё нормально ли хранить код в контроллерах в zoomx? В разных контроллерах же может понадобиться один и тот же код, и его бы куда-то вынести.
Лёша
20 сентября 2022, 19:49
modx.pro
787
0

Комментарии: 3

Александр Туниеков
20 сентября 2022, 23:28
0
Грубо говоря есть несколько типов людей использующих MODX:
— которые просто делают сайты на MODX
— и те которые разрабатывают дополнения для него

Сниппеты изпользуют те кто делают сайты. Вот им один общий сниппет ни к чему. Они просто используют знакомые им инструменты в виде сниппетов.
Те кто разрабатываю дополнения как раз и пищут код в классах дополнения. А в сниппетах его и вызывают. То есть, если мне надо функцию из моего дополнения, я обычно делаю $dop = $modx->getService класса дополнения и вызываю функцию $dop->my_function();
    Артур Шевченко
    21 сентября 2022, 00:06
    0
    В разных контроллерах же может понадобиться один и тот же код, и его бы куда-то вынести.
    В базовый класс, который другие контролеры будут наследовать.
      Сергей Шлоков
      24 сентября 2022, 08:12
      0
      Сниппет в MODX — это концептуальная вещь, базовый элемент шаблонизатора MODX. Он абсолютно органичен и является элементом функционального программирования (шаблонизатор MODX не работает с объектами). У сниппетов есть только один недостаток — код в БД. Но отказаться в MODX от них невозможно!

      По поводу твоего решения. Кроме тебя вряд ли оно кому будет интересно. Но ты можешь попробовать его реализовать для себя. В твоём варианте можно создать сниппет class и использовать его как модификатор — [[Имя_класса:class=`method`]]
      MODX гибкая система. Можно расширить парсер и добавить в него свой тег с собакой (@). Например, [[@class.method:param1,param2]]. Указываешь класс (или объект) и метод и работаешь с ООП. В общем, вариаций может быть много. Ограничивает лишь фантазия.

      В разных контроллерах же может понадобиться один и тот же код, и его бы куда-то вынести.
      Если ты переходишь на уровень фреймворковской разработки, то нужно осваивать соответствующие практики программирования. В помощь литература и другие источники. Например, один из подходов качественного кодинга — концепция тонких контроллеров, когда вся бизнес-логика выносится из контроллера на уровень приложения (application layer). Т.е. в контроллере вызывается какой-нибудь сервис, он обрабатывает данные, возвращает контроллеру, а тот отдаёт их пользователю (через view или напрямую).
        Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
        3