O @ raphael-at-digital-pianism me pediu para postar esta lista de coisas que acho erradas com o XML do componente da interface do usuário da grade adminhtml, então aqui vai:
O que há de errado com o XML do componente de interface do usuário da grade adminhtml?
- Ciclo de feedback lento durante o desenvolvimento
- Dificíl de entender
- Difícil de depurar se algo der errado (principalmente apenas comparando com XML no núcleo)
- Muitos detalhes de implementação expostos
- Incentiva a copiar e colar
- XML não foi feito para humanos lerem e escreverem
- Difícil de testar
- Não está claro quais outras opções estão disponíveis
- Muitos clichês e magia (o pior dos dois mundos)
- Acoplado à idéia de exibir dados da tabela do banco de dados
- Muitas seqüências de nomes duplicadas no arquivo
"Crie uma solução melhor", você diz?
Bem, eu não tenho. Mas aqui está uma idéia aproximada de como eu, como desenvolvedor, gostaria de poder criar grades e formulários de administração.
- Crie uma implementação de
GridDataSourceInterface
- O componente de grade usa um
GridDataSourceInterface::getGridItemType()
método para buscar um nome de classe ou nome de interface
- A interface é refletida e todos os getters são usados para determinar as possíveis colunas
- Tipos de coluna são inferidos a partir dos tipos de retorno
- Tipos que não podem ser inferidos automaticamente como tipos de coluna válidos são ignorados.
- A
GridDataSourceInterface
instância de implementação pode ser usada para configurar tipos de colunas e visibilidade não padrão usando métodos descritivos legais, quando necessário.
Os benefícios:
- Definição assistida por IDE de grades (e formulários) por meio do preenchimento automático de métodos
- Padrões sensíveis
- Implementação independente
- Para entidades simples , é necessário escrever muito pouco código
- Comparado à abordagem XML, nenhuma perda de recursos
- Extensibilidade via interceptores
- Se as interfaces de classe forem concluídas, a definição de grades e formulários também poderá ser tão declarativa quanto XML (mas muito mais simples)
- Corresponde ao "modo de pensar" do Magento 2s para classes de contrato de serviço
- Nenhuma alteração na interação atual com o código de front-end necessário (o mesmo tráfego por cabo)
- A classificação e a configuração da coluna de front-end podem continuar funcionando exatamente como agora
- SEM MOAR XML
Com relação à pergunta original, não acho que usar o antigo estilo Magento 1 para criar adminhtml faça a interface certa.
Só estou defendendo que a nova declaração de grade baseada em XML deve ser substituída por algo melhor o mais rápido possível.