Registrando Hooks do WordPress usando outra classe
No post de ontem, falei sobre os construtores de plugins do WordPress e a razão de por que os hooks não deveriam estar no construtor.
Embora eu tenha mencionado várias maneiras de lidar com o registro de ganchos, não me preocupei em entrar em detalhes para cada uma dessas estratégias. No que me diz respeito, eles merecem seu próprio artigo para fornecer o máximo de detalhes possível sobre como configurar algo.
Por exemplo, um dos métodos que compartilhei afirmou:
- É possível criar uma classe que mantenha um registro de objetos e os ganchos com o WordPress.
Em outras palavras, trata-se de registrar hooks do WordPress usando uma abordagem orientada a objetos para diminuir o acoplamento e aumentar a coesão entre os componentes do plug-in.
Mas o que isso significa mesmo? Quais são as vantagens que ele traz, como é configurado e como é usado?
Registrando ganchos do WordPress
Se você está lendo isso, provavelmente está familiarizado com o sistema de gancho do WordPress, a ordem de como eles são acionados e como uma função ou classe pode registrar suas funções com o WordPress para que possam executar qualquer trabalho que precisem.
E muitas vezes vemos classes fazendo isso por conta própria. Dependendo do projeto, eu mesmo faço. Para quem não conhece, geralmente é algo assim :
<?php
add_action( 'plugins_loaded', 'acme_start' );
/**
* Start the machine.
* https://www.youtube.com/watch?v=ysoMOefPyRs
*/
function acme_start() {
$plugin = new AcmeColumn();
}
Mas tudo isso pode ser dividido em classes mais coesas para, em última análise, dar a elas ainda menos responsabilidade (uma coisa boa) e diminuir o acoplamento entre uma classe ou conjunto de classes com o WordPress.
Um exemplo de um design que vou detalhar neste post.
A natureza contra-intuitiva disso, porém, é que exigirá pelo menos uma outra classe. Mas aqui está como funciona.
Configurando
Para os propósitos deste exemplo, usaremos apenas uma classe simples que registrará algum tipo de ação com o WordPress. A ideia para a arquitetura funciona mais ou menos assim:
- Existe a classe principal que tem a função que queremos conectar ao WordPress.
- Existe uma classe responsável por orquestrar a conexão da função da classe ao WordPress.
Fácil o suficiente, certo? Mas aqui está o problema: a classe responsável por registrar as funções de uma determinada classe com o WordPress é o ponto que requer uma decisão de design.
Primeiro, vamos chamar a classe HookRegistry para que possamos nos referir a ela corretamente. Em seguida, vamos chamar a classe com as funções que queremos conectar AcmeColumn simplesmente para representar uma classe que adiciona uma nova coluna ao painel da página na área de administração do WordPress.
Com isso em vigor, a decisão de design se resume a isso:
- O HookRegistery deve saber sobre AcmeColumn?
- A AcmeColumn deve saber sobre o HookRegistry?
Eu sei que existem outras maneiras de organizar isso e também existem estratégias de como lidar com isso (como inversão de controle) e esses são tópicos que valem a pena explorar, mas para manter essa ideia inicial o mais direta possível, vou tabelar isso para uma postagem futura.
Usando a classe
Dadas as opções acima, passaremos uma instância de AcmeColumn para o HookRegistry quando as classes forem instanciadas durante o processo inicial de inicialização do plugin WordPress. Isso pode ser algo assim :
<?php
add_action( 'plugins_loaded', 'acme_start' );
/**
* Start the machine.
* https://www.youtube.com/watch?v=ysoMOefPyRs
*/
function acme_start() {
$registry = new HookRegistry();
$acme_column = new AcmeColumn( $registry );
$acme_column->start();
}
Em seguida, sempre que for a hora de AcmeColumn registrar sua função no WordPress, chamaremos o HookRegistry e o instruiremos a fazê-lo.
Primeiro, AcmeColumn :
<?php
class AcmeColumn {
private $registry;
public function __construct( $registry) {
$this->registry = $registry;
}
public function start() {
$registry->add_hook( 'filter', 'manage_edit-page_columns', $this, 'add_page_column' );
}
public function add_page_column( $page_columns) {
$page_columns['template'] = 'Acme Column';
return $page_columns;
}
}
Em seguida, o HookRegistry :
<?php
class HookRegistry {
public add_hook( $type, $name, $object, $method) {
$type = strtolower( $type );
if ('filter' !== $type || 'action' !== $type) {
return new WP_Error( '1', 'No proper hook type defined.' );
}
}
private function add_filter( $name, $object, $method) {
add_filter( $name, array( $object, $method) );
}
private function add_action( $name, $object, $method) {
add_action( $name, array( $object, $method) );
}
}
Opcionalmente, também podemos manter uma lista das várias classes e ganchos que foram registrados. Isso pode ou não ser útil dependendo de sua implementação, então estou compartilhando apenas como um "aqui está algo que você pode querer fazer".
E isso poderia ser assim (usando uma matriz associativa simples):
<?php
class HookRegistry {
private $registry;
public function __construct() {
$this->registery = array();
}
public add_hook( $id, $type, $name, $object, $method) {
$type = strtolower( $type );
if ('filter' !== $type || 'action' !== $type) {
return new WP_Error( '1', 'No proper hook type defined.' );
}
if ('filter' === $type) {
$this->add_filter( $name, $object, $method );
} else {
$this->add_action( $name, $object, $method );
}
$hook_info = array(
$type,
$name,
$object,
$method,
);
$this->registry[ $id ] = $hook_info;
}
private function add_filter( $name, $object, $method) {
add_filter( $name, array( $object, $method) );
}
private function add_action( $name, $object, $method) {
add_action( $name, array( $object, $method) );
}
}
Observe que na classe acima, agora ele aceita um $id como parâmetro. Existem várias maneiras de identificar as informações que estão entrando em um registro, a mais fácil delas é criar a ID você mesmo.
No entanto, se você quiser usar algo como o nome do gancho ou o nome da classe, isso também funcionará. Apenas observe que, como é um array associativo, ele só pode manter um único valor por chave, então você pode acabar destruindo dados anteriores se não for cuidadoso.
Independentemente disso, isso é algo que considero opcional, mas se for implementado, é importante garantir que você tenha as funções adequadas para recuperar uma instância do objeto por uma chave.
Um de muitos
Como acontece com qualquer coisa relacionada a esse tipo de trabalho, é possível rearquitetar ou reorientar isso de uma maneira que funcione de maneira diferente ou que atenda às suas necessidades. O objetivo não é mostrar o padrão definitivo de como fazer algo, mas uma maneira de abordá-lo e adaptá-lo (como qualquer padrão de design).
Além disso, o objetivo é garantir que nossas classes mantenham as responsabilidades para as quais foram criadas, permitindo que elas se registrem no WordPress conforme necessário. Desta vez, porém, a classe não precisa fazer isso sozinha.
Em vez disso, ele passa a responsabilidade para uma classe que tem a responsabilidade exclusiva de registrar esses ganchos. Portanto, embora introduza mais classes, aumenta a coesão e diminui o acoplamento.
Isso oferece benefícios em manutenção, testes e design geral.