É melhor triggersr ganchos específicos ou ganchos genéricos com parâmetros?

Estou criando um plugin de formulário para lidar com formulários que podem ser conectados ao uso de ações / filtros pelos desenvolvedores.

Meu plug-in precisa ser capaz de lidar com diferentes formas com diferentes conjuntos de filtros e vejo 2 maneiras de fazer isso.

Método 1

Incêndio de ganchos específicos para cada forma.

Então código como este poderia ser chamado de formulário no meu plugin:

$formId = 'contact'; $errors = apply_filters('forms_validate_' . $formId, $errors, $data); 

E poderia ser usado assim:

 add_filter('forms_validate_contact', function($errors, $data){ if(empty($data['name'])){ $errors['name'] = 'Name is required'; } return $errors; } 10, 2) 

Método 2

Passe um parâmetro para a function de chamada.

Então código como este poderia ser chamado de formulário no meu plugin:

 $formId = 'contact'; $errors = apply_filters('forms_validate', $formId, $errors, $data); 

E poderia ser usado assim:

 add_filter('forms_validate', function($formId, $error, $data){ switch($formId){ case 'contact': if(empty($data['name'])){ $errors['name'] = 'Name is required'; } break; } return $errors; }, 10, 3) 

Existem exemplos no núcleo do WordPress onde este tipo de problema é abordado?

Existe um método preferido para lidar com isso?

Solutions Collecting From Web of "É melhor triggersr ganchos específicos ou ganchos genéricos com parâmetros?"

O método 1 é muito mais robusto e extensível, na minha opinião.

Método 1: Para adicionar ou remover formulários, ou outra funcionalidade, você apenas adiciona ou remove funções. Em particular, você pode fazer isso de outros arquivos, como módulos separados do seu plugin ou outros plugins externos. Penso que este é o principal argumento a seu favor: extensibilidade e modularidade.

Método 2: Para adicionar ou remover formulários ou outras funcionalidades, você precisa modificar uma function existente, que é muito mais propensa a erros. Uma declaração de mudança como a do método 2 facilmente fica fora de controle. A lista de casos pode ser muito longa, e é fácil introduzir bugs assim que você tiver vários filtros com o mesmo tipo de declaração de switch. Por exemplo, você pode querer filtros para validação, exibição de formulários vazios a serem preenchidos, exibição do conteúdo de formulários preenchidos, gerenciamento de database … Portanto, agora você tem um monte de funções cada uma com uma lista muito longa de casos de switch , que você precisa manter a sincronia.

(Eu tive uma experiência ruim disso com uma extensão popular para formas de gravidade – não é incontrolável se você é disciplinado, por exemplo, mantenha a lista de casos na mesma ordem em todas as funções, mas também não é bonito).

Localizando erros: muito mais fácil com o Método 1: o culpado geralmente será o filtro ou a forma recém-adicionada, em vez de algum erro tipográfico inadvertidamente introduzido naquela function muito longa do Método 2.

Exemplos: você encontrará toneladas de exemplos do Método 1 no wordpress core (por exemplo, https://developer.wordpress.org/?s=post+type&post_type%5B%5D=wp-parser-hook ), mas não lembro uma única instância do Método 2.

Faça o nome do gancho específico para o que ele faz, e não onde ele é chamado. Não passe vários parâmetros, porque isso não é fácil de se estender. Passe um object de parâmetro em vez disso.

Exemplo

Crie o object de parâmetro com uma interface para injeção de dependência:

 interface Validation_Parameters { public function id(); public function errors(); // not a good name … public function details(); } class Form_Validation_Parameters implements Validation_Parameters { private $id; private $errors; private $details; public function __construct( $id, $errors, $details ) { $this->id = $id; $this->errors = $errors; $this->details = $details; } public function id() { return $this->id; } public function errors() { return $this->errors; } public function details() { return $this->details; } } $params = new Form_Validation_Parameters( 'contact', new WP_Error(), // should be prepared better. [ 'request' => $_SERVER['REQUEST_URI'] ] ); 

Agora, passe no seu filtro:

 $valid = apply_filters( 'form_is_valid', TRUE, $params ); 

Um desenvolvedor de terceiros pode lê-lo agora, mas não alterá-lo, para que os outros possam contar com sua estrutura, porque não há como corrompê-lo.

 add_filter( 'form_is_valid', function( $bool, Validation_Parameters $params ) { // do something and return a value });