Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Realizar configurações e personalizações dos campos presentes nos Fields Editor, possibilitando a configuração de máscaras personalizadas, nomes de exibição dos campos, por exemplo, utilizando recursos de banco de dados para sanar este problema
Para que serve
Exibir maneiras de tornar um software mais maleável, realizando customizações simples através da própria aplicação e que de outra forma demandariam mais tempo. Tornar o processo de personalização mais simples e menos traumático, facilitando a vida do usuário final
Em que situação o tema é útil
Aplicar boas práticas de desenvolvimento. Tornar softwares autoconfiguráveis. Minimizar o tempo de configuração de suas aplicações. Maximizar o aproveitamento de recursos do banco de dados. Proporcionar maior facilidade em adicionar ou alterar os recursos já presentes em seu software.
Resumo do DevMan
Uma vez mais trataremos um assunto amplamente discutido entre desenvolvedores: Fields Editor. Criaremos uma solução em nosso exemplo que ilustra como realizar configurações / personalizações para contornar este problema. Através destas customizações será possível realizar as configurações que você faria no Fields Editor, dentro de sua própria aplicação. Isto pode nos proporcionar grande facilidade em questões de manutenção. Utilizaremos em nosso exemplo recursos avançados do banco de dados, explorando as tabelas de sistema do banco de dados Firebird, permitindo desta forma que consigamos realizar uma customização através da leitura dos campos de cada tabela de nosso sistema.
Nós como desenvolvedores, sempre somos tentados a desenvolver soluções criativas, que possuam qualidade, agilidade, praticidade entre outros tantos fatores que agregam valores ao nosso produto. E é claro que para concretizar este desafio, além de criatividade, é necessário muito empenho para criar recursos realmente úteis e que facilitem nosso trabalho. Quando nos deparamos com um software grande e complexo, é possível perceber um grande esforço para realizar configurações, isto se deve a preparação do sistema para adequar-se a qualquer tipo de ambiente e impossibilitando que o próprio usuário efetue estas configurações.
Esta situação trata justamente uma importante questão que quase sempre exige grande esforço: a customização. A ideia de customizar um software, se bem aplicada, pode lhe trazer inúmeros benefícios tais como, facilidade de manutenção e ou criação de novos recursos, desenvolvimento mais ágil, automatização dos processos e muito mais. É claro que este tipo de estratégia sempre demanda de uma grande análise, pois engloba várias questões, além de que isso pode ser visto por cada desenvolvedor de forma diferente. A grande questão no nosso caso é: “O que vamos customizar em nossa aplicação?”.
Como já disse em outros artigos, uma das maiores preocupações dos desenvolvedores que criam uma mesma aplicação compartilhando vários bancos de dados é justamente o problema com os diferentes tipos de campos no Fields Editor (numéricos principalmente). Muitos acreditam que este seja um grande problema, porém, veremos uma solução que nos permite a customização destes campos por meio dos recursos de bancos de dados.
Em nosso caso trataremos questões de configurações internas, que muitas vezes influenciam na performance de sua aplicação. Definiremos maneiras de configuração dos Provider Flags de cada um dos campos. Com isto, teremos total controle do modo de atualização de nossas tabelas. Porém, para realizar tal tarefa, necessitaremos conhecer um pouco da estrutura interna do banco de dados (no nosso caso o Firebird) utilizando as tabelas de sistema juntamente com domínios, que nos permitirão a customização e identificação de importantes informações para o nosso objetivo.
No decorrer do artigo, veremos como esta solução pode tornar mais ágil a manutenção, pois todas as tarefas de configuração dos campos serão realizadas dentro da própria aplicação, dispensando a necessidade de abrirmos o código-fonte, podendo realizar configurações automáticas como: máscaras, nomes para exibição, forma de atualização e/ou comportamento dos campos entre outras coisas, nas quais você necessitaria modificar seu projeto, compilá-lo e só assim distribuí-lo para que as mesmas surtissem efeitos.
Para isso passaremos por três etapas na qual teremos: um detalhamento do nosso ambiente e/ou problemática, a criação do banco de dados e por último a criação de nossa aplicação de teste. Utilizaremos em nosso exemplo o novíssimo Delphi 2010 e Firebird 2.1 para o desenvolvimento da aplicação, lembrando que o exemplo é perfeitamente aplicável a qualquer outra versão.
Compreendendo o ambiente
Imagine uma situação onde temos um banco de dados com cinquenta tabelas, e algumas, com pouco mais do que trinta campos entre os mais variados tipos como: Varchar, Float, Date, Integer entre todos os outros campos que você já está acostumado. Muitos podem falar que não há nada demais nisso (e realmente não há), porém, pense se você tivesse que criar uma configuração para cada um destes tipos de campos dentro de cada uma destas tabelas. Este é um problema quando se deve realizar tamanha configuração em ambientes complexos. Agora, que tal uma aplicação que possui a capacidade de se autoconfigurar? Esse é o nosso desafio. Criar uma aplicação que possua tal característica.
...
