As bibliotecas xLibrary, para o trabalho com DHTML compatível com todos os navegadores, contém um nutrido grupo de funções que ademais estão separadas em vários arquivos de código Javascript. Estas funções devem ser importadas através do código fonte das páginas que fazem o uso elas.

O que às vezes não é tão simples é conhecer que grupo de funções deve-se importar em cada momento, já que existem muitas bibliotecas que ademais têm dependências entre si.

Em versões anteriores de xLibrary a maioria das funções mais habituais se encontravam em um arquivo chamado x_core.js e em muitos casos bastava inclui-lo. Um problema desse arquivo é que quase sempre continha muito mais código do que realmente utilizávamos. Para que o arquivo das bibliotecas ocupe menos e seja transferido mais rapidamente pela Rede, em certas ocasiões editei simplesmente a mão, para tirar aquelas funções que não se utilizavam.

Nota: Os primeiros exemplos do Workshop de Cross-Browser DHTML incluem o mencionado arquivo x_core.js porque a ferramenta X Library Compiler ainda não estava criada.

A partir da versão 4.0, a ordem do código mudou um pouco e agora não basta com incluir x_core.js. Agora há que utilizar uma ferramenta chamada X Library Compiler, que está preparada para criar o arquivo de bibliotecas otimizado para o uso em nossa aplicação web. X Library Compiler (XC) faz uma análise do código de nossa página e gera um arquivo com o código que necessitamos incluir, ou seja, personaliza as bibliotecas, criando um arquivo que inclui só aquele que necessitamos.

Com isto simplificam-se dois aspectos. Por um lado, não temos que nos preocuparmos por qual biblioteca devemos incluir e por outro, o código que incluímos sempre é certo que contém as partes estritamente necessárias das xLibrary.

Utilizar XC para criar o arquivo .js a incluir

O problema de utilizar XC é que é um pouco complicado em um princípio. XC está programado em VC++ para Windows e tem que se executar por linha de comandos. Ademais, temos que criar um arquivo de configuração para que faça exatamente o que necessitamos. Trataremos de explicar os passos necessários para que qualquer pessoa possa utilizar XC.

Nota: este procedimento está descrito seguindo a metodologia da versão 4.0 de xLibrary. Pode ser que mude em versões posteriores.

1) Acessamos através da linha de comandos ao diretório onde está XC.
É o diretório onde se descompactaram as xLibrary. Pode ser algo como C:\x\xc.

2) Criamos um arquivo de configuração do projeto
É necessário criar um arquivo de texto com as configurações para que XC opere tal como nós desejamos. O arquivo tem que ter extensão .xcp, por exemplo, meuprojeto.xcp.

O arquivo de configuração tem uma sintaxe especial, que veremos sobre o próprio arquivo de exemplo:

; XC Project: meuprojeto
options
libpath ..\lib\
appfiles
..\..\meusexemplos\animacao_texto_3.html

Qualquer linha que comece por ";" é um comentário. Logo, a primeira linha é um comentário.
Na segunda linha se indicam as opções. Não indiquei nenhuma opção, portanto estamos assinalando que opere com as opções por padrão.
A terceira linha é a rota relativa para o diretório que contem as bibliotecas.
A quarta linha que coloca "appfiles" indica que se procederá a escrever a rota onde estão os arquivos que fazem o uso das funções de xLybrary.
Na quinta e sucessivas linhas indica-se a rota, também relativa, para chegar aos arquivos de nossa aplicação que fazem uso de xLibrary. Pode-se indicar um ou mais arquivos.

3) Executar XC
Agora temos que colocar em funcionamento a ferramenta xLibrary Compiler para gerar um arquivo .js que teremos que incluir nas páginas web que utilizem as bibliotecas cross browser. Para isso, desde o diretório onde se descompactaram as xLibrary e no subdiretório onde está o arquivo xc.exe, algo como C:\x\xc, se executa o mencionado arquivo xc.exe enviando como parâmetro o nome do arquivo de projeto que havíamos criado antes.

C:\x\xc>xc meuprojeto

4) Obter o arquivo gerado
Se a execução de XC tiver sido correta gera-se o arquivo que nossas aplicações deveriam incluir. Se tiver falhado, costuma ser porque escrevemos mal alguma rota ou algo assim. Não obstante, as mensagens de erro são bastante descritivas, o que facilitam as cosas se algo vai mal.
O arquivo gerado terá o nome meuprojeto.js. Simplesmente podemos copiar esse arquivo, situa-lo em nossa aplicação e inclui-lo através da página web.

<script src="meuprojeto.js" type="text/javascript"></script>

Este código serviria para incluir o arquivo meuprojeto.js. Neste caso se supõe que o arquivo a incluir está no mesmo diretório que a página que o inclui.

Opções de XC

Incluem-se algumas opções de configuração de XC, que passam desde a criação de logs até marcar se se deseja ou não continuar as dependências entre funções de xLibrary.

• cmp - Se for verdadeiro, indica que se deve comprimir o arquivo gerado. A compressão elimina as quebras de linha e alguns comentários. (Verdadeiro por padrão)
  
• lws - Se for verdadeiro indica que se deve conservar os espaços em branco. (Por padrão é falso)
  
• nln - Se for verdadeiro indica que se deve conservar as quebras de linha nas linhas que não estiverem vazias. (Por padrão falso)
  
• bln - Em caso verdadeiro, conservam-se as linhas em branco. (Padrão Falso)
  
• log - Se for verdadeiro, criam-se arquivos de log. (Por padrão Falso)
  
• lib - Em caso verdadeiro, gera-se o arquivo de biblioteca. (Verdadeiro por padrão)
  
• glb - Se for verdadeiro, inclui globals.js. (Padrão é verdadeiro)
  
• dbg - Se for verdadeiro faz-se um debug no arquivo de log. (Falso por padrão)
  
• dep - No caso de ser verdadeiro se incluem dependências na biblioteca. Quando está em falso é útil para criar uma biblioteca a partir de uma lista de símbolos de X Library. O autor do programa usa esta opção para criar um arquivo biblioteca como x_core.js (que inclui a maioria das funções) ou x_event.js que inclui funções para administrar eventos. A lista de símbolos a incluir se escreve no arquivo .xcp, na seção appfiles, comentada com um ";". Pode-se ver o arquivo x/x_core.xcp para ver um exemplo.

Outro exemplo de arquivo de configuração que incorpora algumas opções é o seguinte:

options +log +dbg -cmp
libpath ..\lib\
appfiles
..\..\meusexemplos\outroexemplo.php
..\..\meusexemplos\xyz.php

As opções indicadas neste arquivo são que se crie um arquivo de log (o arquivo de log se criará com o nome do projeto e extensão .log), que se incluam informações de debug no log e que não se comprima o código da biblioteca resultante. Neste caso foram indicados dois arquivos de aplicação que contém código Javascript. Os arquivos onde estão os scripts Javascript podem ter qualquer extensão, neste caso .php.

Conclusão

Sem dúvida XC é uma ferramenta útil para manter o jogo de funções estritamente necessário para nossos scripts. Embora o próprio autor comenta várias linhas de desenvolvimento que está embaralhando para melhorar esta ferramenta.

O único problema que encontrei é que em um de nossos scripts tínhamos utilizado uma função das xLibrary dentro de um setTimeout() de Javascript e XC não tinha detectado esta função e não havia incluído dentro da biblioteca gerada. Por exemplo, em um código como este:

setTimeout("xShow('ampliacao')",50)

Com um código como este, XC passava por alto que estávamos utilizando a função show() e portanto não a incluía.

A ferramenta é recente no momento de escrever este artigo, portanto é possível que quando alguém leia estas linhas, este tipo de erro (e outros que possa haver) já tenha sido resolvido e inclusive, que a aplicação tenha melhorado ou modificado o modo de trabalho.