segunda-feira, 9 de maio de 2016

Revoluções silenciosas...

Certas funcionalidades do Genexus mudaram silenciosamente na Ev3, nenhum alarde foi feito, talvez devido a operação lava jato, no Brasil, estejamos nos acostumando com noticias explosivas e ruidosas, e quando a coisa é mais discreta não damos a devida atenção. Desta vez acredito que Genexus nos entregou um modelo um pouco mais flexível, portanto, melhor.

Estou falando sobre a determinação da tabela base e estendida, tema fundamental para quem desenvolve sistemas no Genexus, e que já tivemos a oportunidade de apresentar aqui no Genexando em dois artigos.


O fato é que Genexus define a tabela resultante (tabela base) que será utilizada para recuperar registros quando programamos um for each, e também as tabelas que irão complementar a informação que desejamos, definindo um conjunto chamado tabela estendida, que é a soma da tabela base e das demais complementares.


O que devemos fazer em um comando for each é dizer quais atributos desejamos, a ferramenta faz o resto.
 
Tomemos como exemplo o modelo apresentado acima. Se programarmos um for each, como o apresentado a seguir, com os atributos ClienteNome, CidadeNome e PaisNome, teremos como tabela base a Cliente e a estendida Cliente-Cidade-Pais.




Não será necessário fazer nada, para que tenhamos uma pesquisa completa na tabela Cliente com o nome da cidade e país incluída na apresentação, este modelo é natural no Genexus, e muita gente utiliza isto sem perceber o recurso.


A revolução ocorreu no seguinte sentido, uma nova cláusula no for each foi entregue, a base transaction, ou seja, podemos informar a transação que originará a tabela base do modelo. Desta forma poderíamos programar de forma explicita a transação Cliente no for each. Para transações com dois níveis teríamos que colocar o nome da transação e o nome do segundo nível, por exemplo, NotaFiscal.Produto. Algo como:



O fato é que podemos alterar a base transaction do for each para apontar para outra tabela qualquer, e aqui apresentamos o efeito da revolução. Se por exemplo, dissermos que a base transaction do exemplo seja a Cidade, nos Genexus anteriores teríamos um erro no for each, pois o Genexus não alcançaria o ClienteNome, e como resultado, um ruidoso erro indicando um não relacionamento entre os atributos.

Na versão EV3 do Genexus, o erro de não relacionamento não ocorrerá e em seu lugar teremos um aviso que o ClienteNome não poderá ser alcançado. Observe que a tabela base do exemplo passa a ser Cidade, como determinamos no for each Cidade, e Cliente passa a não fazer parte da solução.


Podemos levar este cenário ao extremo, ao apontarmos como tabela base uma que não poderá ser resolvida por meio do conceito da tabela estendida, façamos uma pequena modificação no modelo, acrescentando um conceito de Empresa que possui Clientes.



Se pegarmos o mesmo for each anterior e apontarmos para Empresa, nenhum atributo poderá ser alcançado pelo conceito da tabela estendida, e o Genexus será compreensivo e não apresentará nenhuma mensagem de erro, apenas avisos.



Portanto, muita atenção na leitura do Navigation View para não deixar as mensagens de warning passarem desapercebidas. Acredito que este novo modelo ficou melhor, porém exigirá mais atenção do desenvolvedor.

Apoiemos as revoluções silenciosas, e também as ruidosas, desde que sejam importantes.