sexta-feira, 31 de dezembro de 2010

Genexus dos Sonhos!

É estranho como temos a capacidade de criticar coisas prontas, mas a incapacidade de criar coisas novas, ou me expressando melhor, como nossa velocidade em criticar é muito maior que a velocidade de criar. Tenho observado essa característica humana ao longo da minha existência, e o pior que muitas vezes recorro a isso também com uma eficiência absurda.

Por favor, entendam esse POST não como crítica, mas como criação, pois o objetivo aqui é contribuir com idéias... E há certo tempo tenho sido incomodado por um sentimento de sugerir idéias para melhoria do Genexus. E entendo a Artech como uma empresa diferenciada, inclusive muito atenta às necessidades da comunidade, provendo evolução constante da ferramenta, também busca a ferramenta ideal. Portanto, ai vai minhas inocentes contribuições.

Linguagem:


1) Ponto-e-virgula: Acredito que a principal necessidade seria a unificação das diversas linguagens e formatos utilizados, e que vem dificultando um pouco o aprendizado da ferramenta. Quero dizer aqui o seguinte, em certos lugares se obriga a colocar ponto-e-virgula e em outros não. De vez em quando isso incomoda um pouco, como por exemplo, quando se escreve uma expressão gigante numa Condition de Grid e, ao se esquecer do tal ponto-e-virgula, se perde tudo.

2) If: é outro recurso que poderia ser unificado, por exemplo, o formato utilizado em fórmulas não é o mesmo que se pode escrever na aba EVENTS, seria muito interessante se o formato simplificado das fórmulas pudessem ser utilizados nos eventos e vice-versa.

3) Sou programador C, e apesar da grande maioria não gostar muito dessa praia de ondas bravas, acredito ser uma das melhores já criadas até hoje, principalmente devido ao recurso de simplificação. Como a possibilidade da criação de blocos com as chaves { ... } em comandos de controle. Isso simplificaria um pouco a programação, evitando-se os EndIf, EndFor, ....

4) Os operadores ++ e -- de C também são muito interessantes

5) O Ricardo Oliveira postou uma idéia muito interessante que eu também compartilho da mesma idéia, que é a utilização de blocos para a programação nativa (csharp, java, ...) , assim como acontece atualmente, com as sections [web], [win], [bc].

O formato seria algo como:

[csharp]
{

...

}

Isso permitiria a construção de código de forma mais elegante, e apesar do recurso de programação nativa não ser muito indicada, de vez em quando salva.


Interfaces:


1) Templates: Permitir ao próprio programador definir templates para a geração de FORM´s em transações. Ou seja, define-se um modelo HTML, e indica-se o local onde o Genexus inseriria os controles dos diversos atributos da transação (algo semelhante ao que ocorre nas masterpages atuais). Isso possibilitaria a geração de interfaces totalmente otimizadas e de acordo com as regras que o próprio mercado define. Por exemplo, atualmente difunde-se o uso de <div> e <span>em substituição às <table>, consideradas obsoletas, visto que os primeiros aceleram a velocidade do browser.

De certa forma, a definição de templates permitiriam a interferencia do Analista no próprio funcionamento do Gerador, otimizando-o para as suas necessidades.

2) Controles distintos para um mesmo atributo: Isso de certa forma já acontece hoje, quando se define o tipo EDIT com Description na estrutura da transação (Ver POST Anterior), mas seria interessante expandir um pouco mais esse recurso, com novas propriedades na estrutura da transação para se definir o tipo de controle a ser gerado nas situações:
  • O atributo chave primária em sua transação original: EDIT
  • O mesmo atributo como chave estrangeira em outra transação: EDIT com Description, Dynamic List Box ou Dynamic Combo Box,...
  • O mesmo atributo como chave estrangeira em um GRID: EDIT com Description, Dynamic List Box ou Dynamic Combo Box,...
Atualmente temos várias propriedades para designar tipos distintos de titulos (Title, Contextual Title, Column Title), que tal expandir esse mesmo mecanismo para se definir tipos de controles.



3) Relatórios dinâmicos: sou fã da programação dinâmica, e tudo que permita influenciar um determinado modelo em tempo de execução, adequando-o a realidade do próprio usuário. Talvez um vício da programação em C, onde tudo era possível de se construir dinamicamente. Deixe te dar um exemplo, que tal se tivéssemos na aba layout de relatórios a possibilidade de incluir e remover dinamicamente controles (atributos, variáveis,...), ou seja, que pudéssemos definir quais controles estaríamos interessados em apresentar em determinada situação. Num grid por exemplo, poderíamos gerar um relatório dinâmico, a partir das colunas selecionadas pelo próprio usuário.

4) Dinamismo na interface gráfica: Permitir definir certos controles na interface web que sejam carregados através de Ajax. Por exemplo, utilizando-se vários combos dinâmicos o controle retorna ao servidor e toda a interface é carregada novamente. Poderia haver um processo em que ao trocar as condições de filtro, de um dynamic combo, e o browser acionaria Ajax para recarregar apenas o que foi influenciado pela mudança.

Programação


1) Biblioteca de procedimentos: Nas linguagens tradicionais (C por exemplo) tínhamos as LIB's que eram as coleções de procedimentos que podíamos importar em outros projetos. Java possui Classes que podem ser guardadas em WAR´s e utilizadas em outros projetos.

Genexus poderia permitir a criação de classes de procedimentos gerados para utilização em outras Kb's sem que fosse necessário utilizar o recurso exportar e importar xpz's. Lembrando que este mecanismo atualmente faz com que os procedimentos sejam compilados e gerados novamente. Com bibliotecas teríamos uma melhoria significativa no desempenho do projeto, pois o que está pronto não precisaria ser reconstruído.

Tenho duvidas se com External Object isso não se encontra disponível, preciso verificar.

2) Operador NOT IN:  Em situações de pesquisas na base de dados em que se busca registros que se encontram em uma tabela, mas, não em outra, poderiam ser resolvidas com o operador NOT IN, ou seja, a diferença entre dois conjuntos. Atualmente para programar isso é necessário dois for...eachs, no mínimo, gerando processamento no programa ao invés do database, o que torna a aplicação mais lenta.


Modelagem

1) Subordinação Lógica: Em algumas ocasiões o Genexus, ao modelar automaticamente a base de dados, cria relações automáticas que não apontam na direção que o desenvolvedor pensava inicialmente, gerando controles de Integridade Referencial sobre tabelas que não possuem relação direta. Pois ele sempre que encontra relação, aponta para o conjunto de índices mais restritivos (completos).

Talvez fosse interessante, em alguns casos, permitir (via configuração) que o desenvolvedor escolhesse a relação que deseja gerar entre tabelas.

Bom, por enquanto é só, talvez futuramente possamos acrescentar alguma coisa a mais na lista.

Controle sobre os Controles da Interface

Esse titulo é um tanto quanto estranho, mas serve bem ao propósito deste POST, as vésperas de um novo ano, espero que com muitos POSTS.

O objetivo aqui é como podemos ajustar a interface Genexus, de forma que a própria ferramenta gere para nós uma interface interessante, sem que tenhamos que alterar formulário por formulário, muitas vezes perdendo a automação automática.   E uma característica conhecida nas interfaces Genexus é que se ao se definir alguma coisa na estrutura da transação, todo o sistema será afetado por essa modificação.  E isso ocorre com praticamente tudo, exceto a seleção do tipo de controle da interface web.

Ao se definir qualquer controle diferente de EDIT na estrutura de uma transação para um atributo do tipo chave primária, essa definição não afetará a interface da própria transação, mas todas as demais que utilizam esse atributo.  Por exemplo, na transação Pais, definimos na estrutura da transação, para o PaisId, o tipo EDIT com Description. 

Na imagem a seguir é possivel visualizar o controle EDIT com Description selecionado para PaisId, e o resultado na interface.
No entanto, na interface de cadastro de Paises, não ocorre alteração no controle de entrada de PaisId, e o mesmo continua como um EDIT simples. Já na interface de Clientes, o controle de PaisId passa a ser do tipo EDIT com Description.
Quanto a utilização em GRID, ocorre que PaisId também é apresentado em forma de EDIT com Description, não sendo portanto necessário apresentar PaisNome.  Mas atenção, PaisNome tem que constar no GRID para que a informação apareça corretamente (Visible=false, resolve a questão).

Com isso é possível usar os recursos do próprio Genexus para obter soluções interessantes com nenhum  esforço, ainda mais nesse período de festas, pois, temos outras coisas mais importantes pra fazer!.