Olá pessoal!
Antes de mais nada, você já gastou um tempo considerável (e por vezes nada legal) desenvolvendo a lógica para a tela de seleção de um simples report? Se sim, este post lhe ajudará a tratar telas de seleção mais facilmente através de uma classe global a ser criada.
Tratar telas de seleção usando o comando “LOOP AT SCREEN” tende a ser muito chato e consumir algum tempo quando se desenvolve e se faz a manutenção de sua lógica interna. Assim, eu desenvolvi uma classe bem simples que me ajudou muito em alguns reports que ando fazendo na Nestlé. Ela ajuda no tratamento de simples eventos como mudar as propriedades (por exemplo: input, visibilidadede) de parameters e select-options.
Irei explicar como a classe funciona a partir de um simples exemplo. Imagine que você deve criar um report com 2 radio buttons e alguns outros parameters e select-options. Quando algum radio button é selecionado, os campos que correspondem a esta opção deverão estar prontos para a entrada do usuário (isto é: estar visíveis, habilitados e etc) e os campos da tela de seleção que não correspondem a esta opção deverão estar desabilitados e alterados de outras formas.
Como bom desenvolvedor, antes de quebrar o teclado codificando, você quebra a cabeça primeiro analisando características e possíveis evoluções deste programa. Você nota que há realmente muitos campos que precisam ter suas propriedades alteradas de acordo com a escolha dos radio buttons. Para dificultar a situação, as propriedades a serem alteradas dos campos são diferentes e a lógica da tela caminha a passos largos para se tornar complexa e difícil de se manter. Ainda, após uma conversa com o cliente, você também percebe que o número de opções (radio buttons) poderá aumentar no futuro.
Antes de ler este post, provavelmente você usaria o fabuloso comando “LOOP AT SCREEN”. Dentro deste laço provavelmente haveria comandos CASE e IF (cheios de condições) e muitos literais com nomes de campos da tela de seleção. Sem dúvida, isso não seria o código mais limpo que você viu na vida, mas com um pouco de paciência ele atenderia o requisito atual. Todavia você que lê o ABAP101 e assina seu feed sabe que pode desenvolver uma classe global (aqui chamada de “ZCL_DYNPRO_HANDLER“) para lhe ajudar nessa tarefa sujeita a erros.
Os objetos criados a partir desta classe representarão configurações (ou estados se preferir) da tela de seleção em um dado momento. Os métodos desta classe alterarão as propriedades dos parameters e select-options da tela de seleção. Para saber as propriedades destes componentes, dê uma olhada na estrutura “SCREEN” na SE11.
No começo do seu report, você configurará os objetos criados (um para cada possível configuração de tela). Após isso, bastará apenas aplicas essas configurações quando necessário. Como no nosso exemplo havia somente duas opções possíveis, dois objetos serão instanciados.
Abaixo se encontra os códigos do nosso report e da classe global. Mais uma vez feitos para o tio San entender.
Z_DYNPRO_REPORT
Z_DYNPRO_REPORT_INC
Obviamente nem tudo é perfeito.. vamos analisar essa classe.
Prós e Contras
- Fica bem fácil entender como a lógica da tela de seleção funciona pois ela está quebrada em diferentes objetos e sua configuração é centralizada
- Muitas configurações podem ser criadas apenas usando referências a objetos
- A lógica de telas de seleção fica padronizada
- Uma dada configuração é aplicada apenas com uma chamada de método
- (Essa na minha visão é a mais bacana) Como a configuração atual da tela é usada como base quando se cria um objeto (no método construtor), é possível economizar tempo e linhas de código quando se tem duas ou mais configurações que são similares. Cria a configuração que será mais semelhante as outras, aplique-a e então crie os outros objetos de configuração. Nesses últimos somente será necessário configurar a parte delta
- As configurações devem ser detalhadas usando o maior número possível de campos da tela) para facilitar a manutenção do código
- Como cada objeto carrega uma tabela, que representa a configuração da tela, mais recursos são necessários. A boa notícia é que provavelmente essas tabelas serão pequenas.
- Um laço deve ser feito a cada chamada de método de configuração. (nessa versão da nossa classe :- )
- Algumas propriedades são fazem sentido quando são tratadas de forma coletiva. Não faz muito sentido por exemplo habilitar um campo para entrada mais o tornar invisível.
Melhorando a classe
Você pode começar criando os métodos que alteram as propriedades dos campos que faltam. Basicamente, haveria um método para cada componente da estrutura SCREEN. Mas aqui vão outras idéias que você pode tentar (e comentar os resultados aqui é claro)
- Como os métodos set são basicamente iguais, tente desenvolver um método dinâmico que trata todos os casos possíveis;
- Adicione métodos “get” para retornar propriedades de campos;
- Adicione métodos que tratam a mudança de uma mesma propriedade de um conjunto de campos.
- Crie métodos que resolvam o ponto negativo de número 4 apontado acima. Neles mais de uma propriedade será alterada. Dê nomes diferentes de “set” para estes.
- Tente resolver o laço a cada chamada de método. Lembre-se que a tabela de configuração possui uma chave bem simples (o nome do campo) a ser modificado.
Em um post futuro, compartilharei também uma solução para facilitar o preenchimento de listboxes (parameters). Ele é um forte candidato a ser membro desta classe global.
Conclusão
Lógica de tela de seleção não deveria consumir muito tempo de desenvolvimento. Usando uma classe bem simples muito esforço de desenvolvimento e manutenção pode ser poupado.