segunda-feira, 19 de julho de 2010

Rompendo relações implícitas!

Genexus é uma ferramenta tão poderosa que as vezes precisamos desligá-la, isso pra fazer algo de forma mais 'estúpida'. Estou falando a respeito da capacidade da ferramenta em encontrar relações entre tabelas dentro do modelo da base de dados.

A regra é que quando programamos for...eachs aninhados (um dentro do outro) a ferramenta sempre tentará encontrar a relação entre duas tabelas, e para isso buscará encontrar a relação no conjunto de tabelas estendidas. Isso é o que se chama relação implícita, e se o Genexus encontrar a tal relação, o programador não precisa programar cláusulas where para conectar as duas tabelas.

Vamos estudar um modelinho.



Por exemplo, se queremos relacionar a tabela B com a tabela D, o que existe em comum entre as duas é a tabela C, e o atributo c*, desta forma se programarmos dois for...eachs aninhados, conforme abaixo, teríamos:

A relação implícita existente entre os dois for...eachs será o que existe em comum entre as duas tabelas, que corresponde ao atributo (c*).

A questão que colocamos é como desligar essa maquininha de relações implícitas do Genexus, digamos para fazer algo como relacionar manualmente B com C, B com E, ou mesmo F com A, isto em situações diferentes de c=@c.?

Existem várias práticas que poderiam ser aplicadas, e como queremos fazer algo 'estúpido', podemos substituir os for...eachs aninhados por for..eachs paralelos. Claro que ao fazer isso estamos quebrando todas as relações existentes.  E não me pergunte a respeito de desempenho, por favor.

Tente uma subrotina.



Fazer algo assim tão anti-natural em Genexus pode auxiliar em algum problema mais prático, principalmente causado por projetos complexos de projeto de bases de dados, e relações não tão implícitas assim.  Mas não se esqueça que Genexus quase sempre tem sempre razão no quesito database, e a solução dele sempre será a mais eficiente.

sexta-feira, 9 de julho de 2010

Melhorando o tempo de expiração da sessão

Uma das dificuldades enfrentadas pelos usuários em sistemas WEB é o fato de que, antes de completar um formulário, com muitos dados, complexo, chato,  o tempo de sessão expira antes do pressionamento do botão confirmar. Já viu isso? eu já

O ASP.NET utiliza o arquivo web.config para configurar a aplicação web, existindo diversos parâmetros que podem ser controlados. Nosso interesse nesse instante é apenas no tempo de expiração da sessão.

Utilizo o exemplo abaixo para estabelecer um tempo de expiração de 2000 segundos, de inatividade do usuário.



Os parametros significam:

  • Mode.  inproc, que significa que o estado da sessão é gerenciada como um processo no servidor, e qualquer se o processo é desligado o estado é perdido, em outras palavras, se você desligar o servidor por um curto periodo de tempos as sessões serão todas desligadas
  • Cookieless. é um parâmetro booleano e significa que não será gravado cookie na máquina do cliente.
  • Timeout. esta opção determina o tempo em que uma sessão será considerada válida a partir de uma determinada chamada, ou seja, considera-se o horário da chamada + o tempo definido nesse parâmetro para que a sessão seja fechada automaticamente.  A cada chamada do usuário ativo fará com que o contator seja zerado novamente.
Para maiores informações melhor consultar a fonte: http://msdn.microsoft.com/en-us/library/ms972429.aspx

quarta-feira, 7 de julho de 2010

Mais uma pra coleção: GXM_badnum

Mais uma pra minha coleção de coisas esquisitas! GXM_BADNUM. Já viu isso?

Situaçãozinha estranha, erro aparecendo em um local onde nunca havia aparecido antes. E em outro lugar, também com a entrada numérica.  Nesse outro local o erro aparecia com uma mensagem: The value is not a valid number.


Passado o pânico inicial que segue algo tão estranho, me recordo que criei a kb recentemente, e importei os objetos do programa para essa kb nova, e algo me diz para verificar o idioma da aplicação.

Batata! kb criada originalmente em Inglês e quando se informa um valor 2.00 o resultado é um belo valor 200.00, ou seja, está acontecendo erro na conversão de , para . e vice-versa.

Solução: colocar Translation type=Static, e Translate to language=Portuguese, Build all e pronto, já era.

terça-feira, 6 de julho de 2010

O perigo de ter duas mulheres!

Esse assunto é tão delicado que até o título é perigoso. Nunca aconteceu comigo, mas já vi esse filme várias vezes. E acho que você também. Faz parte do quotidiano da raça. Algo do tipo chamar a Jane de Francisca é algo inconcebível no relacionamento, e aí é que mora o perigo. Tão grande que pode causar até o pior...

Imaginemos então uma situação diferente, um sorteio através de uma lista de nomes, alguns homônimos, tipo José da Silva, José da Silva, José da Silva,..., e mais alguns Josés da Silva. No momento do sorteio, se sair José da Silva, complicou a vida.

GeneXus também tem um problema quando se trata de coisas iguais na interface, e olha que nem é culpa dele, a tecnologia web tem dessas coisas. E da mesma forma que acontece nos ‘causos’ citados anteriormente, aqui também a coisa pega.

Por exemplo, se você colocar um ClienteId e ClienteNome no Grid1, claro que o ClienteId não precisa ser apresentado, pode ficar oculto, e no Grid2 que trata das compras do Cliente, colocamos ClienteId, CompraData, CompraValor, e por algum acaso da necessidade, deverá se expandir o registro de compras, ... , poderemos estar chamando a Jane de Francisca.

Acontece que existem dois ClienteId’s em dois grids distintos, que poderão possuir valores distintos também, nunca se sabe. Por exemplo, o primeiro Grid1 mostra todos os clientes, e o Grid2 mostra as compras que ainda não foram pagas por todos os clientes. Ou seja, os grids podem operar de forma desassociada um do outro.

Daí meu amigo, é crime! Como referenciar uma operação de expansão de um registro do Grid2, se você não controla o valor de ClienteId?

Confuso? Isso é o que dá duas mulheres ao mesmo tempo, confusão, então simplifique, nunca coloque na mesma interface atributos ou variáveis iguais, senão estará casando com duas mulheres, ou mais, ...

quinta-feira, 1 de julho de 2010

Boas maneiras!

Quando você era criancinha sua mamãe e papai lhes ensinaram uma série de 'boas maneiras', e talvez a que mais fixou em seu cérebro foi: NÃO FALE PALAVRÕES. Pois é esse ai guardamos por toda vida.

Genexus e C# também nos ensinam boas maneiras, principalmente referentes aos 'palavrões' não aceitos.  Tive uma aula de boas maneiras ontem, até que bem interessante, e tirei algumas boas conclusões, que compartilho com vocês.

Boas Maneiras 1) Como dar Nó na Gravata:

O nó que tive que resolver foi o seguinte, programando uma SDT simples, com algumas informações referentes a emails, como destinatário, título, mensagem, essas coisas, e tive a brilhante idéia de programar tudo em inglês (mania).

O resultado foi um belo STD com a seguinte forma:


Fala sério, ficou até bonitinho hein. Mas acontece que por causa desse lindo SDT foram horas de canseira, e não havia jeito de entender o erro de compilação do C#.

Conclusão:  Nunca utilize palavras reservadas ou tipos pré-definidos em SDT's, tais como TO, MESSAGE,..., e veja que usei várias em um mesmo local, isso é que foi falta de educação.

Dai fica simples dar o nó, basta entrelaçar as coisas corretamente.

Boas Maneiras 2) Não cometa extravâgancias

Esse aqui também mamãe lembrava sempre, mas não teve jeito, de vez em quando acontece. E a minha extravagância foi também cometida no mesmo SDT anterior.

Pensa comigo:  C# é escrito em inglês, Gx é escrito em inglês, ..., então a probabilidade de cometer um erro tosco desse é escrever variáveis, elementos de SDT, DP, em ...inglês.

Pois é, minha mania custou caro, e minha recomendação aqui é: se for cometer uma extravagância dessas não dirija, em outra palavra: CAUTELA.