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?
Comentários Recentes