Widgets do WordPress: uma abordagem orientada a objetos
Anos atrás, criei o WordPress Widget Boilerplate com o objetivo de ser o seguinte:
Um clichê organizado e sustentável para criar widgets usando as melhores práticas do WordPress.
Desde então, não mudou muito em relação à API de Widgets (que veremos mais adiante neste post), mas o que considero como "melhores práticas" mudou. Além disso, o grau em que acho que essa API é uma exemplo de programação introdutória orientada a objetos no WordPress é alta.
Não é porque usa muitos princípios orientados a objetos, não é porque usa padrões modernos (pelo menos no que diz respeito ao PHP moderno), mas porque usa algumas coisas que nos ajudam a reconhecer alguns, digamos, sinais sobre programação orientada a objetos no WordPress.
E isso é algo que não deve ser subestimado: se você está procurando exemplos de programação orientada a objetos no WordPress, procure por APIs que a empregam.
Além disso, se você está procurando maneiras de avaliar seu próprio nível de avaliação de um pedaço de código (muito menos uma base de código) para o uso de classes e alguns dos recursos mais avançados da OOP, por que não ter algum tipo de um teste decisivo para ver como você está?
E a API Widgets faz exatamente isso.
Widgets do WordPress: uma introdução
Então, em uma série menor do que a minha última, pretendo analisar a API de Widgets e fazer algumas coisas:
- mostrar o esqueleto básico de um widget e por que ele é orientado a objetos,
- discutir quais coisas você deve ser capaz de perceber e por quê,
- atualize o Widget Boilerplate diretamente neste site primeiro e depois envie-o para o GitHub,
- construir um widget usando a API com o clichê como base para nosso trabalho.
E neste post, vamos começar com o primeiro ponto acima.
Mas primeiro…
Antes de entrar neste post, recomendo a leitura dos seguintes posts:
- Dois Pilares da Programação Orientada a Objetos: Parte 1 de 2
- Dois Pilares da Programação Orientada a Objetos: Parte 2 de 2
- Aulas de Resumo, Parte 1 – Comportamento de Abstração
- Classes Abstratas, Parte 2 – Classes Abstratas e Interfaces
Uma vez feito (ou se você sentir que já domina os tópicos), estamos prontos para começar.
[restringir pago="verdadeiro”]
Noções básicas da API de widgets
Se você ler a página do manual em Widgets, verá muito conteúdo. Isso é uma coisa boa, mas nem sempre é a melhor jogada ao tentar destilar conteúdo para um público como você, quando você está procurando conselhos práticos e orientados a objetos.
Então, vou selecionar as partes relevantes da documentação da API e aplicá-las ao código que também fornecemos.
O que é um widget?
Acho que a maioria de nós que trabalha com WordPress sabe o que é um widget, mas é importante definir o termo para que todos trabalhemos com a mesma ideia. O manual diz:
Um widget é um objeto PHP que gera algum HTML. O mesmo tipo de widget pode ser usado várias vezes na mesma página (por exemplo, o widget de texto). Widgets podem salvar dados no banco de dados (na tabela de opções).
Com isso em mente, vamos dar uma olhada no código de um widget personalizado, pelo menos um stub dele, e ver o que podemos coletar no que diz respeito à sua natureza orientada a objetos.
A classe de widgets
Antes mesmo de olharmos para o código, sabemos que haverá algum nível de programação orientada a objetos simplesmente porque a documentação nos diz para fazer três coisas:
- Crie a classe do seu widget estendendo a classe padrão WP_Widget e algumas de suas funções.
- Registre seu widget para que ele fique disponível na tela Widgets.
- Certifique-se de que seu tema tenha pelo menos uma área de widget na qual adicionar os widgets.
Neste post, vou me concentrar no primeiro ponto (embora eventualmente cheguemos a como introduzimos nossos widgets em um tema antes que a série termine).
Então, vamos apresentar o código como é apresentado na documentação e falar sobre o que podemos aprender com ele:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Primeiro, notamos que embora tenhamos definido uma classe (que podemos nomear o que quisermos, do meu jeito), ela deve estender WP_Widget. Isso significa que no núcleo do WordPress, existe uma classe WP_Widget. Você pode ver um detalhamento bem organizado do código-fonte nesta página.
Em segundo lugar, a palavra-chave extends indica que estamos usando herança PHP, que é um pilar central da programação orientada a objetos.
Terceiro, existem quatro funções que devemos implementar, duas das quais requerem argumentos. As funções que devemos implementar são as seguintes:
- __construct() que é o construtor básico da classe. É aqui que precisamos ter certeza de que o construtor da classe pai é chamado, se houver um, e então inicializamos quaisquer propriedades que julgarmos necessárias para nosso widget. Vamos dar uma olhada nisso mais tarde na série.
- widget() é responsável pela saída do conteúdo do widget que o usuário disponibiliza utilizando a interface na área administrativa. Ele aceita dois parâmetros – $args e $instance. O parâmetro $args é a informação a ser renderizada na página, e a $instance é uma referência à instância do widget (já que vários widgets podem ser renderizados em uma página).
- form() exibe a interface administrativa com a qual o usuário interage para orientar qual é a saída no front-end do site. Ele também requer o argumento $instance para que as informações fornecidas sejam para o widget real com o qual o usuário está trabalhando (versus todas as instâncias do widget).
- update() é usado para salvar os valores na instância atual do widget. Aceita dois argumentos. O primeiro é a nova instância do widget com valores de atualização que o usuário forneceu (pense em atualizar o valor de um widget de texto ativo) e o segundo argumento é o da instância antiga do widget ou talvez a instância anterior ou talvez ” a instância que continha os valores anteriores.”
Essas quatro funções são necessárias para serem implementadas como parte da API do widget, como parte das funções herdadas da interface estendida e para produzir a funcionalidade básica de um widget.
Isso não significa que mais não possam ser adicionados, mas em boa forma orientada a objetos, provavelmente seria melhor relegar esse comportamento a outras classes. Mas veremos como fazer isso mais tarde na série, quando estivermos criando nosso próprio widget.
Quais são as principais conclusões?
Para ter certeza de que estou claro quanto ao que seria entendido neste post, é o seguinte:
- A API Widgets é orientada a objetos. Não é apenas orientado a objetos porque usa uma classe (embora esse seja certamente um bom ponto de partida), mas também porque herda a funcionalidade construída em uma classe base pré-existente.
- Sempre que herdamos o comportamento de uma classe base ou de uma classe pai, estamos obtendo funcionalidades pré-desenvolvidas gratuitamente. É uma coisa realmente ótima sobre programação orientada a objetos porque nos permite focar especificamente na lógica de programação que desejamos implementar.
Imagine por um momento que você deseja desenvolver um widget, mas toda vez que o faz, você precisa escrever todas as funcionalidades para se conectar ao WordPress para fazer todas as mesmas funcionalidades repetitivas do clichê.
É aqui que a herança e a programação orientada a objetos entram em cena. O código repetitivo é abstraído em uma classe base, portanto, é escrito apenas uma vez e, em seguida, o código no qual queremos nos concentrar é deixado para implementação.
Tudo o que foi dito acima é o que deve ser entendido ao ler esta passagem inicial no código-fonte para uma API básica orientada a objetos no WordPress.
Qual é o próximo?
Na próxima postagem desta série, veremos a natureza orientada a objetos da API Widgets e quais coisas você deve ser capaz de detectar imediatamente lendo o código.
Isso ocorre porque é importante reconhecer certos princípios orientados a objetos na prática e essa é uma boa maneira de avaliar se você é capaz de fazer isso ou não. Se estiver, ótimo! Então vai continuar a ajudar a desenvolver esse músculo. Se não, não se preocupe – ainda ajuda a desenvolver esse músculo.
E isso irá atendê-lo bem à medida que continuamos a avançar cada vez mais para o desenvolvimento WordPress orientado a objetos por meios práticos.
A teoria necessária foi coberta. Então, vamos começar a colocá-lo em prática.