Pull to refresh

Comments 16

Позвольте, Вас немного исправить. Есть неофициальный ответ от представителя MODX LLC о том, что MODx является устаревшим названием платформы. Сейчас правильно писать MODX.
ОК, обязательно возьму это на заметку.
Увидел заголовок статьи, завис, мозг начал выдавать варианты про программирование видеокартами, HDD, RAM…
Предполагал такой вариант. Но все же статья в блоге MODX Revolution, и многим любителям этого движка так или иначе понятно, что такое процессор.
Но рад был бы, если бы кто-то предложил какое-то свое название всему этому безобразию…
Просто я, честно говоря, впервые с этим сталкиваюсь. Поэтому программирование процессорами для меня — это что-то из области забивания гвоздей микроскопами.
Но ведь и процессор — это не всегда железка, так же как и шина, винчейстер и т.п.
В общем как я и предупреждал с самого начала — это статья-размышления. Некоторые вещи сложно бывает назвать своими именами.
UFO landed and left these words here
Для меня более важен момент, что проверки будут проходить как задумали авторы MODX, а не как я криво написал.

И это гарантирует, что расширение, работающее через процессоры, будет работать во всех новых версиях MODX и все системные действия будут отрабатывать штатно.
Да нет, вы меня видимо неправильно поняли.
Первое: я не говорю, что это мое творение. Об этом вообще не было речи. Я говорил о своем стиле разработки, который перенял от MODX.
Второе: я не говорил, что правильно создавать ресурс через объект. Безусловно правильно объект создавать через процессор resource/create
Но предполагалось же, что кто-то вообще не знает что такое процессор, и я хотел вкратце показать маленький процессор, так как $doc->save() интуитивней более понятен для многих, в том числе тех, что с MODX может и не сталкивался, но сталкивался с PDO.
А суть была показать работу вложенных процессоров, так как это в корне отличается от привычных методов написания профильных классов под все случаи жизни.
Я бы только вот уточнил такую деталь, как «классные» процессоры. Все же ребята из MODX сделали огромную работу, переведя кучу спагетти-кода процессоров в классы. И раз речь шла об ООП, то правильнее было бы использовать именно их. За счет наследования кода становится намного меньше в самих процессорах и код более понятный.
Даже если это «классный» процессор, все же суть его остается прежней — выполнить какое-то свое, локальное действие и или вернуть успех, или ошибку. Как бы то ни было, это все равно куча файлов под свои задачи.
Универсальных, удобных, с кучей скрытого, но нужного кода. Подход себя вполне оправдывает, особенно когда имеем дело с аджаксовой админкой.
Да, это я как раз и пытался донести. Самое главное в этом подходе, что независимо от того, вызову я этот процессор на стороне сервера чисто для серверной логики, или запрошу выполнение через коннектор, я знаю точно, что я получу стандартизированный ответ и все будет ОК.
Лично для меня сейчас такой подход кажется наилучшим.
правильно ли я понял, что процессоы (если очень упрощенно) представляют собой аналоги функций?
В более ранних ветках MODX-а именно так и было. Один процессор — как бы одна функция, котораямогла вызывать и другие процессоры-функции, но обязательно возвращала какой-то результат (собственный, или результат других процессоров). А не возврат результата расценивается как отрицательный результат.

Но теперь в MODX процессоры — это уже полноценные классы. Есть базовый класс modProcessor, есть еще несколько классов, производных от него, для выполнения тривиальных задач (create, update, remove, list и т.п.). И теперь своими процессорами можно просто расширять эти базовые, в которых уже прописано много полезного функционала, и процессор на создание своего объекта-записи может уложиться в 10 строк, включая проверку доступов, вывод результата и т.п. Но суть осталась та же — четко вернуть какой-то результат, а задача четко локализована.
Sign up to leave a comment.

Articles