gabrieleb
  • 0
Новичок

Шаблон архитектуры/проектирования плагина — лучше использовать частный шаблон наблюдателя/посредника для подклассов плагина или WP add_action?

  • 0

Я кодирую очень сложный плагин, который организован как родительский «контейнерный» класс и несколько подклассов, где каждый подкласс является необязательным/обязательным элементом, который обычно (но не всегда) сопоставляется с его собственной страницей add_submenu_page.

По сути, это плагин со своим приватным набором, назовем их «подплагинами».

У каждого подкласса/подплагина есть свой (большой) набор add_action и add_filter. Итак, с технической точки зрения, подплагин моего плагина является допустимым плагином WP, просто он не вызывается непосредственно самой WP.

Так как я планировал… на самом деле тонны add_action… Мне интересно, должен ли я реорганизовать свой плагин, используя «частный» шаблон Observer/Mediator, т.е. собирать все соответствующие add_actions только для моего родительского класса и выпекать шаблон для уведомления/пересылки подклассов событий, уменьшая влияние моего плагина на очереди событий WP.

Это хорошая идея или это совершенно не обязательно? Не могли бы вы помочь мне с кодом для рефакторинга класса?

спасибо заранее за помощь, Габриэле

Share
  1. я также думал о лучших шаблонах для использования здесь, вы можете проверить plugins.svn.wordpress.org/wp-favicons/trunk для моего текущего кода до рефакторинга (я кодер-любитель), поэтому в разделе / ​​включает какой-то абстрактный плагин class, а затем каждый /plugin имеет свою собственную «страницу администратора» и наследуется от «plugin», у которого есть некоторые методы по умолчанию для вызова. Может быть, больше в целом: мне также понадобятся еще несколько шаблонов для создания плагинов WP, так как я принял много дизайнерских решений, которые, вероятно, не идеальны или, может быть, даже совершенно не в порядке.

    • 0
    • это именно то, что мне нужно знать! спасибо много!

      • 0
    • +1 Довольно сложный, но и довольно умный подход. Я бы не сказал, что это самый «естественный» подход, но это действительно крутая идея. Одна вещь, в которой вы абсолютно правы, это то, что все начинают автоматизировать настройки API после 2-го или 3-го использования.

      • 0
    • это кажется довольно многословным, но, безусловно, хорошей архитектурой! Я немного покопался в этом, пытаясь лучше понять всю тему

      • 0
    • @kaiser было бы интересно посмотреть, какие подходы люди используют для автоматизации API настроек, и, возможно, посмотреть, есть ли для этого 1 супер правильный способ.

      • 0
    • @edelwater — я бы сказал, вы могли бы сделать довольно инкапсулированный основной класс, а затем добавить почти все способы добавления данных: синтаксический анализ ini/xml/json/yaml/и т. д., создание общих функций для вызова основного класса, а затем sub -функции, которые добавляют предопределения для общих функций, а затем набор конкретных функций, которые решают общие задачи с three_word_string(); … я называю это über-perfekt, но раздувание и перегрузка в одном предложении…

      • 0
    • @kaiser спасибо, что ДУМАЕТЕ об этом. Я оставил это открытым, чтобы подумать об этом. Что хорошо в GPL, так это то, что вы изучаете разные вещи, и это доставляет вам удовольствие.

      • 0
  2. Мне интересно, должен ли я реорганизовать свой плагин, используя «частный» шаблон Observer/Mediator, т.е. собирать все соответствующие add_actions только для моего родительского класса и выпекать шаблон для уведомления/пересылки подклассов событий, уменьшая влияние моего плагина на очереди событий WP.

    Очередь событий имеет фундаментальное значение для WP, поэтому она работает довольно быстро и с каждым разом становится все быстрее.

    Итак, я не думаю, что имеет смысл с точки зрения производительности создавать свои собственные подочереди.

    Рефакторинг вашего кода, чтобы вам не приходилось выполнять каждый вызов add_action() вручную, — это другое дело.

    • 0
  3. Так что… Я в принципе придерживался того же подхода, не знаю, правильный ли он. Я думаю, что многие люди приходят к этому подходу, поскольку он естественным образом вытекает из использования API настроек.

    • Я определяю модули (= 1 страница администратора, поэтому заголовок и т. д.), и каждый модуль имеет плагины (плагины имеют поля, это 1 объект, полученный из абстрактного класса плагина.

    здесь: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-load-configuration.php

    Я думаю, что это автоматически делается большинством, потому что, например, модуль: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php соответствует тому, что нам нужно сделать для API настроек.

    • инициализация загружает модули и плагины (каждый из которых имеет свои собственные действия с фильтрами или присоединяется к фильтру или действиям) {и третья сторона может добавлять плагины к модулям}

    здесь: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-init.php

    (где плагины проверяют, должны ли они быть активированы, если они включены на соответствующей странице администратора) (и могут быть представлены как абстрактные: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class -plugin.php )

    • плагин, полученный из абстрактного класса плагина, затем либо один, либо все: устанавливает дополнительные поля, определяет свой собственный экран справки администратора, проверяет свои собственные поля, выполняет действия на странице администратора, выполняет функции на стороне клиента, такие как фильтры

    • плагин подключается через Addfilter, например: http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/sources/inc/class-module-sources-plugin.php, который всегда соответствует «do filter». присутствует в каждом плагине, поэтому может быть дополнительным абстрактным уровнем, если несколько плагинов повторно используют одно и то же «делать».

    • и может присоединяться к вашим собственным фильтрам в классах на бэкэнде, например, http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/request/request_cache.php добавляет определенные фильтры в фильтр добавления плагинов

    Итак, с другой стороны «бэкэнд-сайта» я определил только свои собственные фильтры, к которым каждый из плагинов может подключаться, например, http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/ class-favicon-factory.php определяет фильтры, такие как «Config::GetPluginSlug(). ‘search'»

    Так что в целом… Я думаю, API настроек естественным образом подталкивает нас к такому подходу.

    Итак… затем некоторые доходят до точки (ваш вопрос), в которой вы могли бы подумать о рефакторинге ваших собственных действий добавления на «что-то еще», что может быть шаблонами наблюдателя / посредника или чем-то еще.

    Но… так как мы следовали подходу WordPress, используя API настроек (все вышеперечисленное), используя это, упрощая для третьих лиц «подключение» к действиям, написание собственных расширений страницы справки и т. д… Я бы придерживайтесь здесь также с add_action просто потому, что «остальная» часть дизайна также следует этому, и это, вероятно, облегчает понимание всего кода.

    • 0
  4. Еще один хороший пример распространения плагина с подплагинами — вот этот.

    • 0

Оставить ответ

You must login to add an answer.