Em defesa do Plone

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Sempre recomendo que coisas importantes recebam a devida atenção.

É por isso que não me incomodo muito em ver sites descartáveis sendo feitos com tecnologias como ASP, JSP ou PHP, naquele modelo antigo que mistura apresentação com lógica.

É como na construção de cenários – você não vai usar madeira se isopor e lycra resolverem. Concreto armado, nem pensar. Site descartável é como aqueles escritorios que são erguidos para vender apartamentos na planta: ele só precisa ficar lá até vender unidades suficientes para começar a obra. Depois disso, vai ser derrubado. Ele nunca vai desenvolver uma goteira ou ganhar mais um piso.

Com sites, a situação é parecida.

Caso seu site seja um cartão de visitas feito pra dar seu e-mail de contato ou telefone, tudo bem você montá-lo com qualquer coisa. HTML estático está bom demais.

Por outro lado, se você precisa viver com um site, é bom fazê-lo direito. É importante separar a aparência dele (que pode mudar radicalmente a qualquer tempo) do conteúdo (que tende apenas a aumentar) e de eventuais aplicações que rodem dentro dele (se seu CMS deixar você fazer esse tipo de coisa).

É por conta disso que eu gosto tanto do Plone. Ele traça uma linha muito nítida entre conteúdo e forma e, por conta de como é construído, em torno de um banco de objetos (e não um banco relacional, como a maioria dos concorrentes) ele torna ridiculamente simples fazer aplicações de workflow ou de gestão de conhecimento.

E quando eu digo ridículo é porque, tipicamente, você só precisa gerar alguns diagramas UML e entregá-los a uma ferramenta que faz o resto.

Uma digressão rápida: no meu livro, guardar documentos dentro de um BD relacional, como faz o SharePoint, é motivo para justa-causa. Guardar ponteiros para um sistema de arquivos é apenas marginalmente melhor. Mas isso é material para outro artigo, não para esse.

E aí eu entro na parte realmente importante: se você tem problemas com sua intranet e gostaria que ela fosse mais manejável, compatível com mais navegadores (diga a verdade – é um porre quando a empresa padroniza em IE 6 porque fez a burrada de criar aplicações importantes que não rodam nem mesmo nas versões posteriores dele, quanto mais em navegadores mais modernos), que pudesse guardar seus documentos do Office (ou do OpenOffice, ou do iWork, se você tem Macs), que tivesse uma busca que funcione (porque você quer encontrar os documentos que colocou lá), que tenha undo sem nunca precisar de um restore do banco de dados (porque todo mundo erra de vez em quando) e que, no geral, envelheça mais graciosamente do que aquelas coisas com que você está acostumado, dê uma olhada no Plone.

Eu sei… Sou – e assumo – um fanboy do Plone. O dieblinkenlights é feito em Plone. Por vários anos o Plone pagou – não paga mais – minhas contas.

O DBL é feito em Plone porque eu sou muito preguiçoso e não quero ter dores de cabeça com o site. Ele simplesmente funciona e tem sido assim desde que ele existe. E é assim que um CMS tem que ser.

Na semana que vem acontece em São Paulo o Plone Symposium South America. É a primeira edição do evento e vale a pena você ir. Vale a pena, não importando se você usa ou não Plone.

Mesmo que você seja um usuário de Joomla, Drupal ou, coitado, de Sharepoint, vale a pena ir. Vale a pena para saber o que o outro CMS, aquele que você não usa, tem para oferecer.

Na pior das hipóteses, você sai com uma lista de features para serem implementados no seu que deve manter seu pessoal de desenvolvimento ocupado por algum tempo. Mas, se você tiver mesmo sorte, você sai de lá um usuário de Plone.

Seus usuários vão agradecer.

Ricardo Bánffy (ricardo@dieblinkenlights.com) é engenheiro, desenvolvedor, palestrante e consultor.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

5 respostas

  1. Bom ponto, Alex.

    Tirando, talvez, a Wikipedia, esses são muito mais aplicações web do que sites propriamente ditos. Nem Flickr nem WordPress.com são coisas que se faria com um gerenciador de conteúdo do mesmo jeito que você faria uma intranet, um site institucional ou um site de notícias.

  2. Bánffy como sempre mandando bem. Agora, esse papo de sites descartáveis em php…Flickr é descartável? Wikipedia é descartável? WordPress.com é descartável?

    E esse papo de misturar lógico e markup numa mesma estrutura só se o desenvolvedor php parou no tempo…

    No mais, ótimo artigo.

  3. «Guardar arquivos em BD é uma solução usada há anos para evitar que arquivos corrompidos por problema de HD sejam perdidos para toda a eternidade.»

    Nossa… não é sempre que tenho chance de ler uma imbecilidade tão grande.

    Parabéns Bánffy!!! Como sempre ótimo artigo.

    Preciso ainda reler com mais calma para captar os pormenores (no trabalho é complicado dar muita atenção).

    []s
    Cacilhas, La Batalema

  4. Guardar arquivos em BDs relacionais é uma péssima idéia – eles simplesmente não foram feitos para isso. Guardar ponteiros no BD relacional para arquivos no file-system é um convite à perda de consistência.

    BDs relacionais também não resolvem magicamente o problema de HDs quebrando: Do mesmo jeito que você precisa de um back-up do banco com os blobs dos arquivos, precisaria de um back do banco sem blobs (menor) e do filesystem onde vivem os arquivos para os quais o banco aponta.

    Seria estranho eu propor o Plone e guardar os arquivos em um filesystem fora do banco de conteúdo: no caso do Plone, o ZODB resolve esse problema muito bem e – o que é importante em aplicações de workflow – preserva o estado dos objetos ao longo do seu ciclo de vida.

    Essa mesma característica de preservar os estados sucessivos é o que permite ao Zope (e ao Plone, por extensão) ter as melhores facilidades de undo de qualquer CMS do mercado.

  5. Não sou defensor de nenhum CMS em particular, mas discordo do seu ataque ao Sharepoint.

    Guardar arquivos em BD é uma solução usada há anos para evitar que arquivos corrompidos por problema de HD sejam perdidos para toda a eternidade. Convenhamos que é muito mais fácil recuperar um backup de BD do que um HD corrompido. Basta ver os sourcesafes da vida baseados em filesystem.

    E, no mais, o Sharepoint realmente não é indicado para apenas CMS.

    O Plone é legal e o Sharepoint também. Cada um no seu quadrado.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *