Modelagem e lógica condicional com OOP no WordPress
A modelagem está se tornando mais comum no WordPress, e considero isso uma coisa boa.
Mas isso não significa que não existam projetos que gerenciamos que usem uma abordagem mais tradicional para exibir modelos ou parciais. Além disso, isso também não significa que estamos isentos de manter bases de código que usam código que não usa um mecanismo de modelagem.
Embora eu ache que modelar é bom, não acho que seja sempre necessário. Isso é conteúdo para outro post, no entanto.
Em vez disso, quero percorrer o processo de usar a lógica condicional de exibir ou não uma parcial em um modelo e fazê-lo usando programação orientada a objetos.
Modelagem e lógica condicional com OOP
Para fazer isso, vamos supor o seguinte:
- Temos um plugin que depende de outro plugin para um recurso.
- O segundo plugin é opcional.
- Se não estiver presente, exibiremos um aviso. Se estiver presente, exibiremos uma parcial.
Direto o suficiente, certo?
A única coisa a notar é que toda essa lógica será mantida dentro do plugin primário (ou seja, aquele que vai verificar a presença do outro plugin).
1 Lógica Condicional do Modelo
A primeira coisa que precisa ser feita é ter uma função que verifique a presença do plugin secundário. A razão para isso é porque o modelo está fazendo algo assim:
E então a parcial pode se parecer com isso (depende da sua implementação):
Por causa de como os modelos são incluídos no WordPress, a função ficará dentro de uma classe e a classe verificará a presença do plug-in.
Se você usar qualquer sniffer de código, ele provavelmente acionará um aviso de que o método não é usado, mas o método é usado, é usado apenas em um arquivo de modelo. Anote em uma aula. Tudo isso para dizer, alguns de nossos farejadores não são tão inteligentes. Ainda.
2 O código do lado do servidor do plug-in
Uma vez que você tenha uma ideia geral de como isso vai funcionar, é hora de escrever o código em sua classe.
Lembre-se, esta é uma função simples: ela só precisa verificar a presença de um plugin. Você pode fazer isso de algumas maneiras, mas a mais comum pode ser usar a função da API is_active_plugin .
Observe que, ao usar esta função, ela se baseia na ideia de que você sabe o nome do plug-in que está usando. Se não, existem outras maneiras, mas isso está fora do escopo deste post.
De qualquer forma, como a lógica é condicional, ela precisa retornar um valor booleano, e é exatamente isso que a função da API acima faz. Portanto, a função do lado do servidor pode ser algo assim:
E como o código do modelo chama essa função (que você vê acima), ele determinará se precisa mostrar uma parcial ou não.
Bastante fácil
Para alguns, isso é algo realmente simples; para outros, é uma abordagem completamente diferente, pois trata de uma maior separação de interesses.
E como continuo a trabalhar com o OOP Fundamentals com os membros do site, acho importante também compartilhar algumas das melhores práticas com aqueles que podem não ser membros, mas estão ansiosos para escrever um código mais organizado.