Comments 16
Позвольте, Вас немного исправить. Есть неофициальный ответ от представителя MODX LLC о том, что MODx является устаревшим названием платформы. Сейчас правильно писать MODX.
Увидел заголовок статьи, завис, мозг начал выдавать варианты про программирование видеокартами, HDD, RAM…
Предполагал такой вариант. Но все же статья в блоге MODX Revolution, и многим любителям этого движка так или иначе понятно, что такое процессор.
Но рад был бы, если бы кто-то предложил какое-то свое название всему этому безобразию…
Но рад был бы, если бы кто-то предложил какое-то свое название всему этому безобразию…
Просто я, честно говоря, впервые с этим сталкиваюсь. Поэтому программирование процессорами для меня — это что-то из области забивания гвоздей микроскопами.
Для меня более важен момент, что проверки будут проходить как задумали авторы MODX, а не как я криво написал.
И это гарантирует, что расширение, работающее через процессоры, будет работать во всех новых версиях MODX и все системные действия будут отрабатывать штатно.
И это гарантирует, что расширение, работающее через процессоры, будет работать во всех новых версиях MODX и все системные действия будут отрабатывать штатно.
Да нет, вы меня видимо неправильно поняли.
Первое: я не говорю, что это мое творение. Об этом вообще не было речи. Я говорил о своем стиле разработки, который перенял от MODX.
Второе: я не говорил, что правильно создавать ресурс через объект. Безусловно правильно объект создавать через процессор resource/create
Но предполагалось же, что кто-то вообще не знает что такое процессор, и я хотел вкратце показать маленький процессор, так как $doc->save() интуитивней более понятен для многих, в том числе тех, что с MODX может и не сталкивался, но сталкивался с PDO.
А суть была показать работу вложенных процессоров, так как это в корне отличается от привычных методов написания профильных классов под все случаи жизни.
Первое: я не говорю, что это мое творение. Об этом вообще не было речи. Я говорил о своем стиле разработки, который перенял от MODX.
Второе: я не говорил, что правильно создавать ресурс через объект. Безусловно правильно объект создавать через процессор resource/create
Но предполагалось же, что кто-то вообще не знает что такое процессор, и я хотел вкратце показать маленький процессор, так как $doc->save() интуитивней более понятен для многих, в том числе тех, что с MODX может и не сталкивался, но сталкивался с PDO.
А суть была показать работу вложенных процессоров, так как это в корне отличается от привычных методов написания профильных классов под все случаи жизни.
Я бы только вот уточнил такую деталь, как «классные» процессоры. Все же ребята из MODX сделали огромную работу, переведя кучу спагетти-кода процессоров в классы. И раз речь шла об ООП, то правильнее было бы использовать именно их. За счет наследования кода становится намного меньше в самих процессорах и код более понятный.
И скажем честно, обычные процессоры после «классных» — херня на постном масле.
Заметка про них и заготовка компонента, с их использованием — там же есть и видео, как легко начать делать новый компонент.
Заметка про них и заготовка компонента, с их использованием — там же есть и видео, как легко начать делать новый компонент.
Даже если это «классный» процессор, все же суть его остается прежней — выполнить какое-то свое, локальное действие и или вернуть успех, или ошибку. Как бы то ни было, это все равно куча файлов под свои задачи.
Универсальных, удобных, с кучей скрытого, но нужного кода. Подход себя вполне оправдывает, особенно когда имеем дело с аджаксовой админкой.
Да, это я как раз и пытался донести. Самое главное в этом подходе, что независимо от того, вызову я этот процессор на стороне сервера чисто для серверной логики, или запрошу выполнение через коннектор, я знаю точно, что я получу стандартизированный ответ и все будет ОК.
Лично для меня сейчас такой подход кажется наилучшим.
Лично для меня сейчас такой подход кажется наилучшим.
правильно ли я понял, что процессоы (если очень упрощенно) представляют собой аналоги функций?
В более ранних ветках MODX-а именно так и было. Один процессор — как бы одна функция, котораямогла вызывать и другие процессоры-функции, но обязательно возвращала какой-то результат (собственный, или результат других процессоров). А не возврат результата расценивается как отрицательный результат.
Но теперь в MODX процессоры — это уже полноценные классы. Есть базовый класс modProcessor, есть еще несколько классов, производных от него, для выполнения тривиальных задач (create, update, remove, list и т.п.). И теперь своими процессорами можно просто расширять эти базовые, в которых уже прописано много полезного функционала, и процессор на создание своего объекта-записи может уложиться в 10 строк, включая проверку доступов, вывод результата и т.п. Но суть осталась та же — четко вернуть какой-то результат, а задача четко локализована.
Но теперь в MODX процессоры — это уже полноценные классы. Есть базовый класс modProcessor, есть еще несколько классов, производных от него, для выполнения тривиальных задач (create, update, remove, list и т.п.). И теперь своими процессорами можно просто расширять эти базовые, в которых уже прописано много полезного функционала, и процессор на создание своего объекта-записи может уложиться в 10 строк, включая проверку доступов, вывод результата и т.п. Но суть осталась та же — четко вернуть какой-то результат, а задача четко локализована.
Sign up to leave a comment.
Парадигма программирования процессорами в MODx Revolution