camaliga para TYPO3

Para a maioria das listas no TYPO3, não é necessária uma extensão própria

Uma empresa quer mostrar referências no site: logo, nome do cliente, setor, descrição curta. Outra quer listar funcionários: foto, nome, departamento, telefone. Uma terceira precisa de uma visão geral de produtos: imagem, título, preço, link para página de detalhe. Três requisitos diferentes, um padrão comum: listas estruturadas com campos configuráveis. camaliga resolve esse padrão como extensão de listas genérica, em vez de desenvolver uma extensão customizada para cada tipo de lista.

A extensão de quizpalme está disponível há anos no TYPO3 Extension Repository e é mantida ativamente. Sua vantagem: um tipo de registro com campos flexíveis cobre 80% de todos os requisitos de lista. A desvantagem: quem precisa de modelos de dados muito específicos (relações aninhadas, multilinguismo no nível de campo, validação complexa) atinge limites.

Cenários típicos de uso

Listas de referências e clientes. O uso mais frequente: logos e descrições de clientes ou projetos em uma exibição em grid. camaliga traz layouts prontos: grid, carrossel, acordeão, exibição em abas. Os dados são mantidos no backend TYPO3 como registros, a exibição é controlada por templates Fluid. Em um cliente com 120 referências, a página de referências baseada em camaliga ficou pronta em 3 dias, incluindo filtragem por setor.

Páginas de equipe e funcionários. Foto, nome, cargo, dados de contato, opcionalmente um texto curto. camaliga mapeia isso por seus campos padrão: título, subtítulo, imagem, descrição, link. Para campos adicionais (número de telefone, departamento), campos customizados podem ser acrescentados via TCA-Override. A alternativa seria EXT:tt_address, que é especializada em dados de endereço e para páginas de equipe frequentemente oferece demais e de menos ao mesmo tempo.

Visões gerais simples de produtos sem funcionalidade de loja. Empresas que querem apresentar produtos mas não vendê-los não precisam de uma loja. camaliga entrega uma lista de produtos com imagem, título, campo de preço e link para ficha técnica. Filtragem por categoria é possível via a atribuição de categorias integrada. Para 50 a 200 produtos sem carrinho, é mais eficiente que Aimeos ou bernetshop.

Arquitetura técnica

camaliga é baseada em Extbase/Fluid e segue o padrão MVC. O tipo de registro central é tx_camaliga_domain_model_content e contém campos para título, subtítulo, descrição, descrição curta, imagem, link, categoria e vários campos customizados. Os campos são definidos no TCA e podem ser estendidos ou reduzidos via TCA-Override no sitepackage.

A exibição é feita por um plugin de frontend com layout configurável. No FlexForm do plugin, o editor seleciona: qual categoria exibir, qual layout usar, quantas entradas por página, se a paginação está ativa. Os layouts são templates Fluid que podem ser sobrescritos no sitepackage. camaliga fornece aproximadamente 15 layouts prontos, da lista simples ao grid filtrado com animação Isotope.

A filtragem por categoria utiliza as categorias de sistema do TYPO3. Cada registro camaliga pode ser atribuído a uma ou mais categorias. No frontend, um menu de filtro é gerado que filtra por JavaScript (Isotope ou filtro CSS) ou por carregamento de página. A variante JavaScript é mais rápida, a variante por carregamento de página é mais amigável ao SEO.

Para ordenação, camaliga oferece várias opções: por título, por data de criação, por ordenação manual (drag-and-drop no backend). A ordenação manual usa o campo sorting do banco de dados e funciona pelo mecanismo de ordenação padrão do TYPO3 no módulo List.

Problemas frequentes e soluções

Layouts parecem diferentes do esperado. Os layouts incluídos do camaliga dependem de certos frameworks CSS (Bootstrap 3/4) ou bibliotecas JavaScript (Isotope, Masonry). Se o site usa outro framework, os estilos colidem. Solução: nunca usar os templates padrão, criar templates Fluid próprios no sitepackage. O esforço para um template próprio é de 1 a 2 horas, depois a exibição é totalmente controlável.

Performance com mais de 500 registros. camaliga carrega por padrão todos os registros de uma categoria e filtra no frontend por JavaScript. Com mais de 500 entradas, o tempo de carregamento inicial se torna perceptível (3 a 5 segundos com 1.000 registros com imagens). Solução: ativar paginação e limitar a quantidade por página a 20 a 50 entradas. Para filtragem baseada em JavaScript: ativar lazy loading de imagens e carregar dados via AJAX.

Multilinguismo requer workaround. camaliga suporta o tratamento de idiomas do TYPO3, mas a tradução de cada registro individual é trabalhosa com mais de 200 entradas. Solução: para listas puramente visuais (logos sem texto), um registro por idioma é suficiente. Para listas com texto, acelerar a tradução pelo workflow de tradução inline do TYPO3 ou escrever um script de migração que importa traduções via API DeepL para as versões de idioma.

Migração e compatibilidade de versões

camaliga é mantida ativamente e suporta TYPO3 v11, v12 e, conforme o roadmap atual, também v13. A extensão segue o ciclo de release do TYPO3 com curto atraso. Instalação via Composer pelo Packagist é possível, instalação via TER também.

Quem migra de uma extensão customizada para camaliga precisa transferir os dados da tabela customizada para tx_camaliga_domain_model_content. Isso é um trabalho de SQL que na maioria dos casos pode ser concluído em menos de um dia. Na direção oposta: quem migra de camaliga para uma extensão Extbase própria pode usar a estrutura de dados como modelo.

Para requisitos mais complexos (registros aninhados, relações entre listas, controle de workflow), recomenda-se em vez de camaliga uma extensão Extbase customizada ou EXT:mask. A Gosign orienta sobre a solução adequada e implementa tanto soluções rápidas baseadas em camaliga quanto extensões individuais.