...
O Cronapp fornece duas funções para um bloco cliente chamar um bloco servidor: a função "Chamar Bloco" e "Chamar Bloco Assíncrono". "Chamar Bloco" usa uma especificação Ajax do navegador de bloqueio síncrono que está ameaçada de descontinuidade pelos navegadores modernos há algum tempo já. Logo, não usem essa função. Nós a mantemos apenas por compatibilidade com sistemas mais antigos (mas será removida no futuro). A função "Chamar Bloco Assíncrono é indicada para esse fim, visto que não bloqueia o navegador, deixando seu sistema mais fluido.
Valores Padrões (Iniciais)
As fontes de dados fornecem um local correto para definir valores padrões para entrada de dados. Muitos clientes usam eventos de cliente "Ao Entrar" e modificam os valores dos componentes. Mais uma vez, não aconselhamos isso, pois é inseguro, pelos mesmos argumentos colocados no tópico sobre "Validações de Entrada de Dados". Logo, assim como as regras de validação, os valores padrões devem estar do lado do servidor.
Observação: Os valores padrões são usados também como valores iniciais de um formulário no Cronapp. Logo, ao clicar em "Novo", o formulário será alimentado com os valores padrões definidos. Tais valores podem ser valores fixos ou valores dinâmicos, obtidos através de blocos (ver figura abaixo).
Figura 1. Exemplo de definição de valores padrões para uma fonte de dados.
Padrões para nomear arquivos
...
É bem comum eventos de tela interagirem com a própria tela. Exemplo: ao selecionar tipo CPF ou CNPJ, o sistema mostra um campo ou outro da tela. Muitos usuários, devido à abstração que o Cronapp traz, não se atentam em usar a camada correta para cada caso. O exemplo dado pode ser executado tanto no cliente quanto no servidor, mas é mais indicado o uso do cliente, pelo motivo óbvio de evitar desperdício de recursos com uma chamada ao servidor com algo que pode ser resolvido no cliente.
...
Organização de blocos em pacotes (pastas)
Devido à velocidade de desenvolvimento, muitos usuários deixam de lado a organização estrutural de seus blocos. É comum vermos listas longas de blocos em uma mesma pasta. Aconselhamos separar blocos em pastas (pacotes) e subpastas (sub-pacotes) por responsabilidade a fim de evitar um código fonte confuso e desorganizado. Exemplo: pacotes como financeiro, administrativo, util, util/data.
...
Uso de Funções
O Cronapp permite a criação de várias funções dentro de um mesmo bloco. É comum vermos usuários criando uma função por bloco, sendo que aquela função só faz sentido para um determinado bloco. Outros casos comuns que vemos são blocos muito longos com pouco reaproveitamento. Tentem reaproveitar mais seus blocos e funções em outros blocos. Não criem blocos muito logos, pois dificulta a leitura e manutenção. Para rotinas comuns, criem blocos utilitários, exemplo, blocos de manipulação de datas, blocos de validação de dados etc.
...
Trabalhar com data e hora em sistemas modernos requer entender completamente o uso de fuso horários. Uma aplicação web ou mobile é composta, em sua maioria das vezes, de banco de dados, servidor e cliente (navegador web ou aplicativo). É necessário entender bem que o fuso de cada uma dessas camadas pode ter especificações diferentes que podem gerar confusões ao implementar seu sistema. Sugerimos a leitura do documento Entendendo o funcionamento dos tipos data e hora para elucidar todas as dúvidas relacionadas ao uso de data e hora no Cronapp;
Garantia de Execução de Rotinas
Uma prática muito comum é o uso do bloco "try" com a opção "finally" para garantir a execução de uma rotina, mesmo que ela falhe. O usuário precisar que uma rotina seja executada mesmo que haja um erro é muito comum, porém muitos usuários fazem isso de forma não segura. Exemplo: Um rotina que abre um arquivo temporário, faz uso desse arquivo e depois o apaga. Muitos usuários fazem como segue:
A figura acima mostra a forma insegura de manipulação de arquivos. Caso o bloco Processa Arquivo apresentar um problema, o arquivo ficará como lixo na pasta. A forma correta e segura é a seguinte:
A figura acima mostra como garantir que o arquivo será removido independente de falhas no processamento do mesmo.
Tratamento de Erros (Exceções)
O Cronapp fornece blocos para Tratar Exceções (try), Criar Exceções e Lançar Exceções. Tais blocos devem ser usados para tratamento de erros para diversos fins, porém um bem comum é apresentar erros amigáveis para usuários. Exemplo: ao usar o bloco de Obter Conteúdo de uma URL e o retorno falhar por algum motivo, você pode capturar o erro e exibir uma mensagem amigável para o usuário.
Uso de Agendador
Logar
Internacionalização
Observe a figura abaixo:
Agendador de Tarefas vs Bloco Agendar Execução
O Agendador de Tarefas foi introduzido no Cronapp a fim de permitir que o desenvolvedor agende execução de blocos em background. Pode-se escolher entre diversas opções de disparadores. Já o Bloco Agendar Execução é uma forma manual de agendar a execução de uma rotina que pode ser executada uma única vez ou em loop. Muitos usuários usam o bloco Agendar Execução para iniciar execução de rotinas em background que se repetem com uma determinada periodicidade. Ex: envio de email diário para usuários ou processamento de notas fiscais a cada 3 horas etc. É uma boa prática usar o Agendador de Tarefas para esses casos, visto que ele foi introduzido no Cronapp para esse fim. O Agendador de Tarefas tem inúmeras funcionalidades que já resolvem os diversos requisitos computacionais do desenvolvimento de uma aplicação. Alguns deles são:
- Garantia de Execução, mesmo que o sistema esteja offline;
- Execução única ou distribuída entre diversos servidores;
- Dezenas de opções de disparadores;
- Tolerância a falha;
- Entre outros...
Log
Um boa prática é logar as informações mais importantes do seu sistema, a fim de rastrear erros e monitorar execuções de rotinas. Para isso o Cronapp fornece uma função chamado Logar com diversas opções para o desenvolvedor. Por padrão, essa função logará em arquivos organizados por data no servidor de aplicações. Tais logs podem ser muito úteis para rastreabilidade em aplicações.
Internacionalização
A grande maioria das aplicações hoje são feitas para o mundo. O desenvolvimento de aplicações locais tem caído muito. Mesmo que a aplicação seja local, é uma boa prática criá-la já pensando nela como global. Isso significa que as mensagens precisam estar em pelo menos dois idiomas, as datas devem ser apresentadas em formatos diferentes, bem como unidades de medidas e máscara monetárias. O Cronapp fornece dezenas de funcionalidades para esse fim.
Parametrização e Perfis
Ao criar um sistema, é bem comum que esse sistema tenha parametrizações diferentes para diferentes implantações (ex, diferentes clientes). É um boa prática usar o Perfis e Parâmetros do Sistema para tal fim. Observe a figura abaixo. Nesse caso estamos parametrizando o um servidor SAP de forma diferente no momento de desenvolvimento e produção.
Uso de Sistema de Arquivo Local
Sistemas modernos devem ser planejados para não terem estado fixo com servidores. Da mesma forma que é uma boa prática não usar variáveis de sessão, pedimos cuidado no uso de arquivos em sistemas modernos. Imaginem uma arquitetura com mais de um servidor respondendo com alta disponibilidade a um sistema. Um usuário logado, pode ter uma requisição caindo em um servidor e, em seguida, outra requisição caindo em outro. É muito comum vermos casos como, por exemplo, upload de um arquivo e um botão para processar o arquivo. Em um ambiente com escalabilidade, o upload pode ser feito a um servidor, porém o processamento pode cair outro, onde esse arquivo não vai existir. Sendo assim, a boa prática para esses casos de múltiplas requisições acessando o mesmo arquivo é o uso de locais de armazenamento na nuvem, como por exemplo, o Armazenamento dos Serviços de Cloud do Cronapp.
Uso de Imagens e Arquivos em Banco
É um péssima prática uso de arquivos ou imagens em banco. O uso de serviços de armazenamento na nuvem para tal fim é o mais indicado. Exemplo: DropBox ou Armazenamento dos Serviços de Cloud do Cronapp.Parametrização