Я кодирую очень сложный плагин, который организован как родительский «контейнерный» класс и несколько подклассов, где каждый подкласс является необязательным/обязательным элементом, который обычно (но не всегда) сопоставляется с его собственной страницей add_submenu_page.
По сути, это плагин со своим приватным набором, назовем их «подплагинами».
У каждого подкласса/подплагина есть свой (большой) набор add_action и add_filter. Итак, с технической точки зрения, подплагин моего плагина является допустимым плагином WP, просто он не вызывается непосредственно самой WP.
Так как я планировал… на самом деле тонны add_action… Мне интересно, должен ли я реорганизовать свой плагин, используя «частный» шаблон Observer/Mediator, т.е. собирать все соответствующие add_actions только для моего родительского класса и выпекать шаблон для уведомления/пересылки подклассов событий, уменьшая влияние моего плагина на очереди событий WP.
Это хорошая идея или это совершенно не обязательно? Не могли бы вы помочь мне с кодом для рефакторинга класса?
спасибо заранее за помощь, Габриэле
я также думал о лучших шаблонах для использования здесь, вы можете проверить plugins.svn.wordpress.org/wp-favicons/trunk для моего текущего кода до рефакторинга (я кодер-любитель), поэтому в разделе / включает какой-то абстрактный плагин class, а затем каждый /plugin имеет свою собственную «страницу администратора» и наследуется от «plugin», у которого есть некоторые методы по умолчанию для вызова. Может быть, больше в целом: мне также понадобятся еще несколько шаблонов для создания плагинов WP, так как я принял много дизайнерских решений, которые, вероятно, не идеальны или, может быть, даже совершенно не в порядке.
это именно то, что мне нужно знать! спасибо много!
+1 Довольно сложный, но и довольно умный подход. Я бы не сказал, что это самый «естественный» подход, но это действительно крутая идея. Одна вещь, в которой вы абсолютно правы, это то, что все начинают автоматизировать настройки API после 2-го или 3-го использования.
это кажется довольно многословным, но, безусловно, хорошей архитектурой! Я немного покопался в этом, пытаясь лучше понять всю тему
@kaiser было бы интересно посмотреть, какие подходы люди используют для автоматизации API настроек, и, возможно, посмотреть, есть ли для этого 1 супер правильный способ.
@edelwater — я бы сказал, вы могли бы сделать довольно инкапсулированный основной класс, а затем добавить почти все способы добавления данных: синтаксический анализ ini/xml/json/yaml/и т. д., создание общих функций для вызова основного класса, а затем sub -функции, которые добавляют предопределения для общих функций, а затем набор конкретных функций, которые решают общие задачи с
three_word_string();… я называю это über-perfekt, но раздувание и перегрузка в одном предложении…@kaiser спасибо, что ДУМАЕТЕ об этом. Я оставил это открытым, чтобы подумать об этом. Что хорошо в GPL, так это то, что вы изучаете разные вещи, и это доставляет вам удовольствие.
Очередь событий имеет фундаментальное значение для WP, поэтому она работает довольно быстро и с каждым разом становится все быстрее.
Итак, я не думаю, что имеет смысл с точки зрения производительности создавать свои собственные подочереди.
Рефакторинг вашего кода, чтобы вам не приходилось выполнять каждый вызов add_action() вручную, — это другое дело.
Так что… Я в принципе придерживался того же подхода, не знаю, правильный ли он. Я думаю, что многие люди приходят к этому подходу, поскольку он естественным образом вытекает из использования API настроек.
здесь: 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 просто потому, что «остальная» часть дизайна также следует этому, и это, вероятно, облегчает понимание всего кода.
Еще один хороший пример распространения плагина с подплагинами — вот этот.