Kaléu P. D. Caminha

Após várias tentativas e algumas experiências bem sucedidas decidi documentar o processo de desenvolvimento conceitual de um componente, o que ele faz, como faz, o que é configurável, etc.

Meu desejo é conversar com a comunidade e propor o desenvolvimento de um manual que auxilie novos desenvolvedores a entenderem não apenas os códigos, mas também o processo de planejamento de uma interface e de desenvolvimento orientado a componentes.

O Todo

Um componente é sempre visto pelo usuário como um “pedaço” ou um “recurso” de interface (em outra linguagem, um quadrado que exibe alguma informação que ele precisa) com a qual ele irá interagir para obter ou inserir alguma informação.

A Informação

Antes de iniciar o desenvolvimento é importante ter em mente quais as informações essenciais que deverão ser exibidas pelo componente e sua ordem de importância. Ter essa visão clara evita desperdício de tempo com retrabalho.

Captura de Eventos

Para que seja exibida a informação correta será preciso interagir com o usuário, o que em interface é comumente feito com o uso de eventos. Existem diversos eventos de interface, teclado, clicks e movimentos do mouse, etc.

As Partes

Para iniciar é preciso separarmos os diversas recursos envolvidos na criação de um componente.

• Ações Públicas: Podem também serem vistas como os casos de uso de um componente, é importante definir a informação de entrada e de saída de uma determinada ação.
• Atributos públicos: Tudo que poderá ser acessado e alterado pelo usuário em tempo de execução.
• Atributos de configuração: Atributos que podem ser indicados na inicialização de um componente.
• Eventos: A forma com mais baixo acoplamento para comunicação de componentes de interface é feita por eventos.

Documentando

Documentar é uma das tarefas mais postergradas no desenvolvimento de software. É possível adquirir uma cultura de programação que torna o trabalho de documentação menos custoso, como por exemplo o uso de annotations, a separação dos métodos da classe por grupo de funcionalidades semelhantes e comentários nos métodos e atributos.

É importante que quem for utilizar o componente tenha claro o uso das quatro partes colocadas acima: “atributos públicos”, “atributos de configuração”, “métodos públicos” e “eventos”.

Além disso, uma descrição de um parágrafo sobre o componente, um print screen dele em funcionamento e um exemplo de caso de uso irão facilitar o trabalho de quem precisa descobrir se um componente é ou não adequado ao seu trabalho.

Conclusão

Estas são apenas algumas observações referentes ao que tenho desenvolvido.

Acredito que a falta de atenção aos ítens colocados aqui podem fazer com que uma empresa julgue o ExtJS (e o uso de interfaces ricas) como “uma péssima ferramenta” quando na verdade o que faltou foi uma mudança de cultura e talvez tempo de treinamento nas novas formas de programar.

Ótimos exemplos de componentes bem documentados podem ser encontrados no site oficial, na área destinada a comunidade.

E você, como é a sua experiência no desenvolvimento de componentes para o ExtJS?