Arquivo

O Ruby on Rails tornou o desenvolvimento de aplicações web célebre pelas suas convenções e pela sua rapidez. Ao privilegiar predefinições sensatas em vez de uma configuração sem fim, permitiu a pequenas equipas construir aplicações apoiadas numa base de dados de forma notavelmente rápida, e moldou uma geração de frameworks web que se seguiram. Dada esta produtividade, era natural que os programadores quisessem um dia gerir também conteúdos editoriais dentro do mesmo ecossistema confortável.

Ao longo dos anos, portanto, uma linhagem de sistemas de gestão de conteúdos foi construída por cima do Rails. O seu objetivo comum é combinar as funcionalidades editoriais que se esperam de um CMS — páginas, gestão de média, fluxos de publicação, conteúdo estruturado — com a flexibilidade de uma aplicação Rails completa colocada por baixo. A promessa é o melhor dos dois mundos: uma experiência de escrita acolhedora sem renunciar à potência e à personalização do framework.

Railfrog e a herança dos inícios

O Railfrog foi um dos primeiros protagonistas desta história. CMS baseado em Rails historicamente distribuído sob a forma de plugin, representava uma tentativa de trazer uma gestão de conteúdos pronta a usar para o mundo Rails quando este ainda era jovem. Como tal, é um marco útil de como a comunidade abordou primeiro o problema, mesmo que, como muitos projetos da sua época, já não seja ativamente desenvolvido.

É importante ser honesto sobre este estado em vez de o recomendar para novos trabalhos. O Railfrog deve ser compreendido como um projeto histórico — uma parte da herança da gestão de conteúdos em Rails — e não como uma ferramenta a adotar para um site que constrói hoje. O seu valor reside agora no contexto: mostra onde a linhagem começou e quais eram as primeiras ambições, o que torna as opções posteriores e mantidas mais fáceis de apreciar.

O modelo de engine das opções atuais

As opções mais recentes e atualmente mantidas adotam uma forma arquitetónica sensivelmente diferente. Projetos como o Comfortable Mexican Sofa e o Spina integram-se como motores (engines) numa aplicação Rails existente, em vez de funcionarem como uma plataforma autónoma distinta que se instala e se opera sozinha. Acrescentam capacidades de gestão de conteúdos a uma aplicação que já controla, em vez de lhe pedirem que construa em torno do CMS.

Este modelo de «CMS como biblioteca» é a distinção-chave a compreender no momento de escolher. Um CMS autónomo tradicional é o centro do seu site, e estende-o através do seu próprio sistema de plugins ou de temas. Um CMS do tipo motor é um componente que monta dentro da sua própria aplicação, deixando o seu código Rails firmemente aos comandos. Os dois modelos adequam-se a equipas muito diferentes e a projetos muito diferentes.

O conteúdo como código, e o seu compromisso

Para as equipas que já desenvolvem em Rails, a abordagem por motor é muitas vezes a mais natural. Permite aos programadores tratar o conteúdo como uma simples parte da sua base de código, gerido com as mesmas ferramentas, testes e pipeline de deployment que tudo o resto, em vez de aprender e manter uma plataforma distinta ao lado da sua aplicação. O CMS torna-se uma capacidade entre outras em vez de um sistema com que se integrar.

Dito isto, a comodidade de tratar o conteúdo como código vem acompanhada de um compromisso na sofisticação editorial. Uma plataforma dedicada e autónoma — incluindo opções não-Rails como o WordPress — oferece geralmente uma experiência pronta a usar mais rica e mais madura para os autores não técnicos, com numerosos plugins e temas. Um CMS Rails do tipo motor dá muitas vezes aos editores de conteúdo uma interface mais despojada, o que se adequa às equipas lideradas por programadores mas pode parecer escasso a uma grande equipa editorial.

Enquadrar a escolha para a sua equipa

O enquadramento honesto da escolha é, portanto, uma pergunta em vez de uma recomendação única. Em que medida precisa de uma interface editorial pronta a usar que os autores não técnicos adorarão, em relação à liberdade de tratar o conteúdo como uma simples fatia da sua base de código Rails que os programadores controlam inteiramente? A sua resposta aponta claramente ou para uma plataforma autónoma, ou para um motor que monta dentro da sua própria aplicação.

O Rails nunca foi a primeira escolha óbvia para um CMS como o é para as aplicações web, e vale a pena enunciá-lo claramente. Mas para as equipas já investidas no framework, as opções baseadas em motores oferecem uma forma coerente de acrescentar a gestão de conteúdos sem deixar o ecossistema em que são produtivas. Conhecer a linhagem — dos primeiros esforços como o Railfrog aos motores mantidos de hoje — ajuda-o a tomar esta decisão com uma visão de conjunto completa.