Faz mais de um ano que andei em busca de uma boa forma de produzir documentos e, não tendo encontrado uma solução perfeita, resolvi reduzir o âmbito do tipo de documentos em causa e concentrar-me na produção dos documentos que tipicamente aparecem durante o processo de desenho e desenvolvimento de software.

A ideia foi simples; partir das funcionalidades de wiki do trac e adicionar a capacidade de exportar cada página como docbook. A partir de uma exportação para docbook, há uma série de opções que se abrem em termos de conversões para outros formatos.

Para chegar aí tinha duas opções, ou converter directamente do formato wikitext do trac, ou partir do xhtml (strict!) que o trac gera a partir do wikitext. A primeira opção consegue-se implementar com umas quantas expressões regulares, mas parece-me talvez mais difícil conseguir prever os casos todos (sobretudo se se tiverem em conta os outros formatos que se podem encontrar misturados com wikitext, nos quais não queria mesmo ter de pensar). A segunda opção pede claramente a utilização de uma folha de estilo XSLT (apesar de também existirem outro tipo de soluções). Convenientemente, encontrei algumas folhas de estilo que fazem já esta conversão, de xhtml para docbook. As mais promissoras foram:

• Uma disponibilizada no DocBook Wiki, escrita por Jeff Beal
• Uma extensão à anterior, que encontrei incluída num módulo de perl, escrito por Kathryn Andersen
• E finalmente, uma outra folha de estilo, com o mesmo objectivo mas escrita por Oliver Steele

Esta última é a mais completa, e com a qual as minhas experiências funcionaram melhor.

Agora basta juntar água (ou por outras palavras, usar os bindings do python para libxml e libxsl) e temos um plugin para o trac ;) A bem dizer, já ando a usar uma versão alpha deste plugin há uns meses. Na altura criei um espaço no trac-hacks para alojar o projecto. Nos próximos dias espero portar o código para o trac 0.11.1 e torná-lo usável por terceiros. Os interessados fiquem por perto ;)

Vou brevemente arrancar com um pequeno projecto em que um dos requisitos será utilzar uma linguagem funcional. Existindo a necessidade de trabalhar com comunicações e com alguma concorrência, tenho andado a olhar para Erlang. A minha experiência com linguagens funcionais tem sido reduzida, aliás, nula, se pensarmos que XSLT e Python têm influências de linguagens funcionais, mas não são linguagens funcionais em si mesmas, por isso estou com alguma curiosidade em ver no que isto dá.

A ideia passa por ter uma aplicação em C# (Mono + MonoDevelop) a falar com um servidor em Erlang, coisa que ainda não estou certo que seja fácil, apesar de haver alguns indicadores de que deverá ser possível.

Para já estou em busca do IDE certo para o módulo em Erlang. Em princípio, devo-me ficar pelo Erlide (um plugin para o eclipse), já que o Erlybird funciona em cima do NetBeans (em relação ao qual não tenho nada contra, mas entre este e o Erlide, prefiro rentabilizar a experiência que tendo com o eclipse) e o Distel não é um verdadeiro IDE (eu até gosto do emacs como editor, mas por muita boa vontade que tenha, aquilo, de facto, não é um IDE).

Ainda na minha demanda por uma melhor linguagem/framework para desenvolvimento para a Web, acho que as seguintes linguagens/frameworks merecem, pelo menos, que as tenha em conta:

• Java, J2EE
• PHP
• Perl
• Ruby
• Python

Contudo, vou já pôr de lado, por razões diferentes, Java, PHP e Perl. Uma das características que procuro é uma forma harmoniosa de separar a produção de documentos XHTML da lógica de negócio propriamente dita. O PHP é muito orientado à produção de documentos, enquanto o Java é mais adequado à codificação da lógica de negócio. Perl, confesso que não conheço muito bem, mas tenho a sensação que se aproxima bastante de PHP, com a desvantagem que não foi desenhada de raiz com o objectivo de gerar documentos para a Web (e não são de excluir também alguns sustos que tenho tido ao olhar para algum código Perl particularmente compacto ;). Com qualquer uma das que conheço se consegue, de alguma forma, separar a produção da markup da lógica de negócio, no entanto, nenhuma delas atinge essa separação de forma satisfatória, pelo menos, para mim.

Com PHP consegue-se esta separação pela utilização de um qualquer sistema de templates dos que por aí andam, deixando apenas a codificação da lógica de negócio ser feita em código PHP propriamente dito. Com JSP também se consegue algo parecido pela utilização de taglibs; a linguagem de template neste caso baseia-se num dialecto XML definido pelo próprio programador. No entanto, até hoje ainda não usei nenhuma solução de templating para PHP ou JSP de que gostasse realmente. Ora as sintaxes de template são intragáveis, ora se confundem com o próprio XHTML (diluindo o valor da estrutura do documento, uma vez que lhe mistura tags que não fazem parte dessa estrutura), ou são tão “comodamente” parecidas com a própria linguagem da lógica de negócio que se ganha demasiado poder ao nível da linguagem de template, perdendo-se toda a vantagem da separação que pretendíamos (mais tarde ou mais cedo o programador cai na tentação de adicionar lógica de negócio nos templates).

Assim, sobra-me analisar mais a fundo Ruby e Python, bem como algumas frameworks que lhes existam associadas. Tenho lido de bom (e de mau) a seu respeito e tenho por isso alguma curiosidade de olhar para elas mais de perto.

Ultimamente tenho usado um pouco de Python e da framework Django, e não estou desiludido. Conto relatar mais dessa experiência proximamente.