Actions por tipo de controle [ Idéias preliminares ]
Marcelo Mrack
ações mais corriqueiras já estão prontas, como:
preencher combos de FK
preencher combos de enumeração
habilitar/desabilitar controles dependentes, como checkbox >
controle
etc.
Muitas vezes, porém, o desenvolvedor quer coisas específicas ou
diferentes. Nesse caso ele usa actions proprias e "atacha" elas nos
controles via anotacoes (mais especificamente, ele atacha a Action no
Field que vai gerar o controle), como abaixo:
@Action({"focusGained","minhaAction"})
Cidade cidade;
Nesse caso, ***além*** da action padrão de carregamento, estara sendo
executada o metodo "minhaAction" no evento "focusGained".
______ A PARTIR DAQUI SÃO IDÉIAS SOMENTE ______
Por outro lado, quando deseja-se desabilitar as actions padroes de um
controle, usa-se
@Actions(disable="*")
Cidade cidade
Nesse exemplo, toda e qualquer action que estiver atachada é
desabilitada. O parametro "disable" recebe o nome da action a ser
desabilitada. Para mais de uma, use-se a virgula como separador,
suportando asterisco e a interrogacao como wildcards.
Vamos a um exemplo: Nao quero usar o metodo padrao de carregamento de
caixas de selecao FK nas cidades. Quero usar meu metodo super legal que
faz isso. Assim:
@Actions(disable="*")
@Action({ "focusGained", "meuMetodoSuperLegal"})
Cidade cidade;
Nesse exemplo, a caixa de selecao de cidades vai ser carregada com o
metodo super legal quando o controle ganhar o foco. A action padrao nao
vai ser chamada pois foi desabilitada. Todas as outras caixas de
selecao continuarao utilizando o metodo padrao.
Nota-se que @Actions tem efeito sobre todas as outras actions, exceto
as actions explicitamente mapeadas no controle corrente. É por isso
que a action do metodo super legal é chamada mesmo com todas as
actions desabilitadas.
Agora, imaginamos que fizemos um metodo super legal que seja generico
(sei la, que usa um cache especifico com maior performance) e queremos
que ele seja usado para carregar todas as caixas de selecao do sistema.
Nesse caso, usa-se a configuracao, como:
actions.JComboBox.componentShown = {minhaActionSuperLegal, *}
Nessa configuracao, explicitamos o tipo do controle, o evento que ele
acontece, a action a ser chamada e o tipo de objeto relacionado, no
caso todos.
Como esse ultimo parametro suporta wildcards (como acima), podemos
fazer coisas como:
actions.JCombox.componentShown = {minhaActionSuperLegalReduzida,
a.b.c.*}
Nesse caso, a configuracao indica que no evento componentShown de todas
as caixas de selecao, a action minhaActionSuperLegalReduzida sera
chamada para qualquer tipo de dado (como a Cidade, acima) que estiver
no pacote a.b.c.*
Ainda podemos querer ter uma action customizada para classes e pacotes
especificos e variados, ***mantendo*** a action padrao de carregamento.
Assim:
actions.JComboBox.componentShown = {minhaActionSuperLegal, a.b.*,
a.d.*}, {java.merlin.actions.DefaultComboBoxFiller, *}
actions.JComboBox.focusGainded = {minhaActionDeEntrada, *Fornecedor,
*Concorrente}
actions.JComboBox.focusLost = {minhaActionDeSaida, *}
Aqui é o seguinte...estamos associando múltiplas actions ao evento
componentShow, onde cada action aponta para um mapeamento de metodo. A
ordem de execucao as actions nesse caso é dada pela ordem em que elas
aparecem na configuracao. Nesse caso, a action super legal é invocada
antes da action do merlin. Como a acion super legal carrega as caixas
de selecao para as classes dos pacotes especificados em primeiro lugar,
quando a action do merlin for invocada ocorre o seguinte: a action do
merlin somente carrega caixas de selecao restantes (que estao vazias).
Como as caixas de selecao para as classes a.b.* e a.d.* nao estao
vazias, a action do Merlin ignora-as. Para as outras combos, a action
padrao é invocada.
As outras actions para ganho e perda de foco sao mais faceis de
compreender. No momento em que o controle ganha o foco, toda e qualquer
classe que acaba com ou Fornecedor ou Concorrente tera a action de
entrada chamada. E na perda de foco, todo e qualquer controle de combo
chamara a action de saida.
Nesse esquema é interessante que podemos plugar eventos e controles de
forma generica e sem limites (desde que eles facam parte da API em uso,
no caso o Swing).
Assim, poderiamos ter algo como:
actions.JToggleButton.action=fooBar,*
que diz que para qualquer botao de estado (check ou radio) queremos
executar a action fooBar independente do tipo de dado associado.
Bem, sao ideias prelimares....
Antes de terminar, digo, porem, que embora isso seja bem flexivel,
ainda temos o esquema de historico, que pode ser utilizado para grande
parte dessas coisas e que, principalmente concordo com voces: queria
reduzir essa quantidade de configuracoes....