terça-feira, 25 de março de 2014

RowsToTabs

Há um ano atras apresentamos aqui no Genexando uma forma de aproveitar o modelo de abas gerado pela aplicação do Pattern Work With em uma transação em outros objetos (Interface com Abas) . De fato esse recurso sempre foi necessário e o modelo que propusemos era 'meio facil' e útil. Interessante que na mesma época um novo UserControl surgiu no Genexus Market Place, que eu acredito que tem potencial suficiente para atender a grande maioria das interfaces que utilizam as tais abas (transações, webpanels, webcomponents), sem a complexidade do componente do Pattern.

Então, nada mais justo que apresentar esse controle, produzido pelo S2b-Group e distribuído gratuitamente para a comunidade. Fiz o teste no Genexus Evolution 2 e resultado foi excelente, muito simples de utilizar.

Como Funciona

Após baixar (RowsToTabs) e instalar o controle no Genexus, o mesmo é apresentado no toolbox com o mesmo nome podendo ser arrastado para o WebForm de uma transação ou WebPanel.

Melhor se jogar o controle dentro de uma tabela com várias linhas, o segredo está em colocar um nome em cada Row (linha) da tabela, que conterá os conteúdos a serem divididos nas abas:


Em seguida em cada linha incluir as informações que se deseja dividir em abas. No meu caso na primeira Row inclui um Grid, na segunda e terceira dois webcomponents.  Lembrando que cada Row deve ter um nome distinto.


Para programar o controle é necessário:

1. Criar uma variável Character(40) e marcando-a como Collection

2. No evento Start programar o conteúdo desta variável, sendo que cada Add()deve incluir uma das linhas que foram renomeadas anteriormente, e em seguida o nome que se deseja que apareça na aba do controle.

3. Na propriedade Tab Pages do controle incluir a variável collection que representa as abas (&TabPage).


O resultado

A interface apresenta um controle bem interessante de agrupamento de informações.


A configuração das cores pode ser feita no arquivo style.css que se encontra na pasta RowsToTabs na pasta web da aplicação.


O que falta

Não tenho criticas quanto ao controle, pois acredito que sua funcionalidade já supera as expectativas, mas creio que pra ficar melhor somente falta neste controle um tratamento de runtime, do tipo um evento que ao clicar em uma determinada aba se dispare um evento que possamos programar. Que possa, por exemplo, possibilitar que definamos o o conteúdo dos webcomponents.



Para saber mais:


  • http://marketplace.genexus.com/product.aspx?rowstotabs,pt
  • http://wiki.genexus.com/commwiki/servlet/hwiki?RowsToTabs+User+Control,


sexta-feira, 14 de março de 2014

Genexus Evolution 3

Enfim, sabemos que a Tilo de fato será chamada Genexus Evolution 3, e quais as suas principais 'evoluções'?

Para obter as respostas a esta pergunta recomendo a você participar do 11o Evento Genexus Brasil, dia 9/4 no Caesar Park Faria Lima em Sao Paulo.

Eu vou, rs...

domingo, 9 de março de 2014

Business Component ou Atualização Direta, eis a questão

Aqui no Blog sou um defensor do uso de Business Component (BC) ao invés da realização da manutenção de registros por meio de Procedures, pois são muitas as vantagens que esse recurso nos oferece, mas como nem tudo nesta vida é um mar de rosas, tomemos alguns cuidados em sua aplicação. Se você ainda não foi apresentado aos BC's, convém dar uma olhada nos artigos anteriores sobre este assunto:
  1. Genexando...: Business Component com Transação de Dois Níveis
  2. Genexando...: Cuidados Básicos com Business Component

Desempenho x Segurança

Esta é a principal questão a ser considerada neste recurso pois ao optarmos por utilizar BC's não temos que nos preocupar com regras de negócio na manutenção dos registros, uma vez que serão aplicadas as que foram programadas na própria transação.  Isso trará maior segurança na operação dos dados, pois os mesmos serão tratados pelo modelo da transação Genexus, que envolve diversos controles como a Integridade Referencial, Unicidade, Regras, tornando muito mais simples e eficiente a programação de novas interfaces.

Por exemplo, uma vez alterada a regra na transação o efeito será imediato, repercutindo em todas as demais interfaces do sistema que utilizam o BC, ou seja o impacto de manutenção do sistema seria mínimo. Talvez este efeito já seja justificativa suficiente para adotarmos BC's. Portanto é um recurso importante a ser considerado em seus projetos.

Como grande inconveniente dos BC's temos o desempenho, que pode degradar muito o projeto dependendo de onde o mesmo é aplicado.  Isso porque o efeito de um LOAD é o mesmo que abrir o registro na própria Transação com o disparo das regras standalone (Default, Noaccept, ...) que por ventura não foram incluídas dentro da cláusula [web]{...}, já discutida aqui no segundo artigo da lista apresentada anteriormente. Como resultado temos uma perda imensa de tempo para realizar coisas que talvez já estejam definidas.

Como se Beneficiar dos BC's

Para simplificar sua vida, proponho a seguir uma tabela com diversas situações que talvez possam te auxiliar na escolha do recurso ideal:

SituaçãoBCProcedures
O registro ao ser inserido deve passar por um filtro de regras que impeçam que o mesmo seja gravado de forma erradasimnão
O registro ao ser atualizado deve passar pelo mesmo filtro de regrassimnão
O registro ao ser apagado pode gerar problemas de Integridade Referencialsimnão
A interface criada protege as informações, de certa forma, permitindo que o usuário faça apenas ajustes em situações totalmente controladas, como por exemplo, permite-se a troca de certo status através de um controle combo cujos valores são sempre válidos.simnão
A interface é do tipo Formulário de entrada e saída, apresentando apenas um único registro a ser manipulado.simnão
A interface é do tipo GRID apresentando diversos registros da tabela, possibilitando que o usuário realize alterações de informações, porém com registros individuais. Por exemplo, cada linha possui um botão para salvar as alterações da linha.sim (*)sim
A interface é do tipo GRID apresentando diversos registros da tabela, possibilitando a manutenção dos dados em todas as linhas ou apenas das que foram selecionadas pelo usuário (através de um checkbox, por exemplo)nãosim

(*) mesmo nesta situação podemos ter perda de desempenho.

Teríamos muitas outras situações a serem tratadas, mas fiquemos com essas por enquanto, pois já são suficientes para chegarmos a uma boa conclusão que é:

Se você está manipulando um único registro opte sempre por BC, pois o resultado trará maior segurança e normalmente nesta situação o problema de desempenho está mais no operador do sistema do que no próprio sistema.  Por outro lado, se a operação envolve mais que um registro, cuidado, BC pode trazer lentidão ao processo, pois os controles e regras da transação seriam disparados em todos os registros.

Recentemente tive que reprogramar uma interface do tipo GRID, regredindo ao modelo da programação de Procedures, pois a lentidão impedia uma boa utilização.  Portanto, fica ai a dica, uma boa observação do resultado final pode te orientar, no futuro, sobre as melhores práticas a serem adotadas em cada caso em seu projeto.