Programa totalmente dinâmico

Não digo totalmente dinâmico, mas se contar com partes pré-construídas é possível sim e fácil.

Entre as complicações de ´tudo dinâmico´ estão validações que são feitas nos formulários, distinções na interface(como outras janelas e botões), etc. As validações podem ser aliviadas em parte com o uso de scripting(com o apoio de uma tabela no banco).

A dificuldade obviamente é maior, o que não pode ser maior é o trabalho na construção de tal sistema, o que invalidaria a tua tese.

No que propõe, quanto a base de dados, as tabelas seriam as mesmas, com a adição do suporte ao dicionário de dados? Aí a diferença estaria apenas na construção dos formulários, não?

Olá a todos,

Exatamente isso, a maior preocupação quanto a esse ssitema seria o fato de se ter uma manutenção rápida e descomplicada, podendo ser feita remotamente e ser desfeita caso seja necessário.

O dicionário de dados(vamos chamar assim), estaria interligado com a base de dados. O maior trabalho do sistema seria a formação do seu padrão (telas, botões, etc.), depois de prontas todas as funções ´genéricas´ responsáveis por montar as telas no padrão, você apenas iria configurar o dicionário de dados e sua função ´montadora´ iria fazer o resto por você.

Isso também acarretaria em um executável mais leve, principalmente se colocarmos essas funções em dlls já que futuramente poderemos mudar os padrões de telas(novas versões do sistema).

O sistema, caso necessário poderia contar também com algumas telas ´pré-montadas´ (apenas quando for realmente necessário).

Imaginem o caso:
´Você tem um novo cliente onde ele percebeu que no seu sistema no cadastro de produtos não existe um campo realmente necessário às necessidades dele, o que você faria?
Muita gente iria no projeto adicionaria este novo campo no formulário, adicionaria o mesmo na base, iria dar manutenção em TODOS os relatórios que usam detalhes do produto e assim iria novamente no cliente instalaria essa nova versão´
Com essa filosofia eu iria apenas enviar um script (instalador de pequeno porte) onde ele iria configurar todo o dicionário de dados para que esse novo campo fosse incorporado ao sistema tanto no cadastro como também nos relatórios (já que também vão ser dinâmicos).

Bem a filosofia é essa, gostaria da opinião de todos delphinianos!
Até mais.

Companheiro, saiba que desde os tempos que eu escrevia meus geradores de programas em Clipper este é um sonho que ha muito tempo persigo para implementar com Delphi.

Muitas coisas já me passaram pela cabeça:

. Usar um dicionário de dados dinâmico e um shell que apenas usasse o dicionário para gerar os cadastros, movimentações, relatórios e gráficos;

. Usar um dicionário de dados estático dentro do IDE do Delphi e, através de assistentes OTA, efetuar a geração de um sistema inicial para ser customizado;

. Usar um dicionário de dados dinâmico juntamente com um engine que pudesse processar scripts, e tais scripts pegassem definições do dicionário ativo para confeccionar programas.

Sem falar que o dicionário poderia auxiliar na criação de novas estruturas de dados (tabelas) e regras de negócio a nível de campo, aplicação, tabela e de relacionamento.

Sugiro que mais pessoas que estejam buscando desenvolver sistemas dinâmicos com Delphi, usando abordagem de dicionários de dados e quaisquer outras que se apliquem ao caso, que se unissem, reunissem suas idéias, e procurassemos uma solução comum para que possamos desenvolver sistemas confiáveis, ágeis, dinâmicos(coisa que o mercado exige ferrenhamente) e eficazes. Eu tb sou a favor desta bandeira.

[]s
Rubem Rocha
Manaus, AM

A ideia é boa... Mas a meu ver, um sistema desse tipo teria uma Interface muito feia...

Hoje em dia o visual conta muito... e dispor os campos na tela simplesmente na ordem que eles constam no arquivo não irá produzir um Form bonito...

Ora, e o que custaria tornar as aplicações dinâmicas mais amigáveis se não pelo advento de ´n´ componentes que existem na Internet que permitem mudar o visual (a.k.a. perfumaria) do Software? Não vejo nada que impeça que uma aplicação dinâmica, como está sendo proposta, tenha um visual agradável!

[]s
Rubem Rocha
Manaus, AM

Mais outro detalhe, muitos componentes de skin aceitam configurar as telas através de arquivos contendo as definições do visual(a.k.a. perfumaria).

[]s
Rubem Rocha
Manaus, AM

Mais outro detalhe. Poderia-se incluir no suposto shell de nossa aplicação dinâmica editores de formulário (E pra isso, tb existem componentens! É só procurar que tem!), onde poderíamos customizá-lo de forma a fazer uso de skins, de acordo com o componente de skin que fosse escolhido.

[]s
Rubem Rocha
Manaus, AM

Nesse caso o que era simples já se tornou complicado novamente... Ou seja, editar o posicionamento dos componentes do form em algum ´outro utilitário´ seria em alguns casos até mais difícil que usar a IDE do Delphi..

Quando me refiro ao VISUAL, não falo de Skin, mas de Praticidade e Agilidade de uso... Não projetar uma interface Rápida, Consistente e Intuitiva, é um erro que pode condenar o uso do sistema...

Se vc algum dia já trabalhou de digitador, sabe que é muito irritante ter que alternar entre teclado e mouse, só pra dar clique no OK para gravar. Até mesmo um ENTER a mais faz diferença para quem é obrigado a cadastrar varias e varias vezes os dados da mesma tela.

Em resumo... pensem em facilitar a vida do usuário final... Ele que irá conviver com o seu programa 8hs por dia.

Olá a todos,

Um sistema com essa filosofia não necessáriamente teria uma interface ruim para o usuário final, temos várias maneiras de fazer vários controles com a ajuda de por exemplo as teclas de atalho, bem como as funções (F1, F2, F3).

Dou como exemplo sistemas ERP que utilizam basicamente vetores para construção de telas e são telas práticas, rápidas, intuitivas e com um ótimo visual. O mesmo acontece com os relatórios e gráficos.

Não consegui encontrar muito material sobre o assunto ligado ao Delphi, creio que seria uma boa oportunidade de gerar novas idéias e conceitos, aproveitaríamos muitos dos recursos de Orientação à Objetos que o Delphi disponibiliza e a manutenibilidade do banco de dados que poderia ser qualquer um (isso dependeria da necessidade do cliente).

Até mais!

Concordo com as colocações do companheiro da Automação Comercial Brasil, mas não vejo isso tanto com obstáculo para que uma aplicação dinâmica possa ter funcionalidades iguais ou semelhantes em sua totalidade em relação as outras que estamos acostumados a escrever.

Quanto à edição de formulários, existem componentes como os da empresa DreamCompany (www.dreamcompany.com) que nos permitem escrever um editor de formulários (este seria o nosso utilitário para edição de formulários) com as mesmas funcionalidades que são oferecidas pelo Delphi (Object Inspector, Paleta de Componentes, etc.). Não vejo isso também com um fator complicador. Pelo contrário. O fato de poder customizar uma aplicação no ambiente do cliente, além de ajudar a dar agilidade que o sistema exige, permite que nos concetremos mais em regras estabelecidas pelo cliente.

Continuo acreditando que é viavelmente possível escrevermos aplicações dinâmicas com o Delphi.

[]s
Rubem Rocha
Manaus, AM

Olá a todos,

Tendo como base esta filosofia, gostaria da opinião dos delphinianos sobre o assunto, é difícil você prever todas as dificuldades que irá encontrar no decorrer do caminho, então caso alguém já tenha trabalhado desta forma (totalmente ou parcialmente) que exponha sua opinião que será muito valiosa a todos que querem seguir esse caminho.

Obrigado,
Até mais!

Sugiro o uso do Micro$oft Access se o sistema não for muito grande.
Ele possui vários assistentes para montar formulários dinamicamente, relatórios, tabela referência cruzada, consultas, consultas em modo totalmente visual etc. É uma verdadeira ferramenta CASE. Em matéria de produtividade é a melhor ferramenta de ´programação´ (apesar de ser interpretada ou ser considerado apenas um documento do M$ access). É de fazer inveja e em alguns casos deixa o Delphi no chinelo :oops: . Possui versões em português e um help digno também em português.

8)

Não consigo ver no Microsoft Access este Santo Graal abençoado! O Delphi é muito mais ferramenta, muito mais consistente e produtiva que o Microsoft Access. E além do mais, o formato .MDB do Access não é considerado um banco de dados, pois não atende totalmente os conceitos ACID que qualificam um SGBD.

E outra, a minha intenção é desenvolver ferramentas, frameworks, assistentes OTA, etc. que permitam um desenvolvimento de uma aplicação dinâmica em Delphi, e não em Microsoft Access.

[]s
Rubem Rocha
Manaus, AM

Ah, esqueci de comentar! O MS Access como ferramenta CASE? Fala sério!!!!

[]s
Rubem Rocha
Manaus, AM

Existem pessoas que são idealistas outras são realistas.
Eu sou realista.
Veja um caso que aconteceu comigo:

Fui contratado por uma grande empresa (que não irei citar o nome) para criar um software que compara-se duas tabelas e localiza-se notas fiscais que não estejam contidas na outra tabela. O gerente pediu para que eu fizesse o orçamento. Comecei a imaginar selects, joins, create, report, forms, datamodule e um monte de parafernalha e penduricalho para fazer o programa em Delphi então dei meu preço R$ 2.200 e 1 a 2 semanas de desenvolvimento.
O garato ao lado do gerente cheio de espinhas, aparentando uns 17 anos e com o cargo Estagiário no crachá pediu permissão para o chefe dele ´tentar´.

Ele abriu o maldito Access vinculou os DBF.
Clicou em consultas assistente localizar não coincidentes, puxou duas tabelas, criou os joins (apenas arrastando os campos) e executou.
Pronto! Em menos de 4 minutos ali estava o resultado.
O gerente olhou para mim e disse: ´Você iria cobrar R$ 2.200 só para fazer isso?´
Não sabia onde enfiar a cara :oops: :roll: !!!!
Então falei: ´Essa parte realmente é super fácil o problema é o relatório´
O garoto então clicou na aba relátorios, assistentes de relatórios selecionou a consulta que ele salvou, escolheu o layout do relatório e executou.
Pronto! Um relatório prontinho em menos de 2 minutos. :?
Então falei: ´Na verdade eu estava imaginando algo mais sofisticado, como uma exportação para o Excel onde o Sr. poderia manipular os dados com mais liberdade.´
O garoto (FD@#$¬) então clicou em Arquivo -> Exportar dados -> Escolheu o Excel -> Informou o caminho onde desejava salvar.
Pronto! Em 3 minutos os dados estavam ali prontos para serem abertos no Excel. :?

Fiquei mudo. Não tinha mais argumentos. Fui derrotado. O garoto fez todo meu trabalho sem sequer precisar sair da máquina e em 9 minutos.

O gerente olhou pra mim e disse: ´Quanto fica a visita?´
Eu falei o preço.
Ele começou a fazer o cheque balançando a cabeça.
Eu imagino que ele se sentiu igual eu quando fui ao médico. E após ser examinado em 3 minutos ele falou que eu não tinha nada e a consulta era R$ 80,00. Que absurdo R$ 80,00 em 3 minutos e pra nada.

Como diz o ditado se não pode derrotá-lo junte a ele.
Então aprendi Access. Agora 80¬ dos meus projetos são em Access, os clientes estão satisfeitos com a produtividade, jogo o prazo lá pra frente, entrego o serviço antes e eles ficam contentes. Pequenos bugs são arrumados na própria máquina do cliente. Não preciso de Notebook ou ir em casa arrumar nada, faço tudo ali mesmo. Nada de atualizador automático.

Podem falar o que quiserem. Que Access não é banco de dados, não é certificado por blá blá blá e não é linguagem de programação. Não importa. É batom na cueca tenho que me render aos fatos.

O gerente analisou tudo de um modo simples, assim como deve ser:
Delphi. Valor R$ 2.200,00+R$80,00 prazo 7 a 15 dias.
Access. Valor R$ 0,00 prazo 9 a 30 minutos.

8)

Cada caso é um caso. Dependendo do tipo de negócio do cliente, o Access pode ser vir muito bem. Até uma m#¬*! de Paradox (sem querer ofender ninguém) pode resolver o problema, dependendo do porte do cliente e do negócio!

Mas continuo afirmando, ele não é banco de dados e muito menos ferramenta Case! Suas observações, para mim, são totalmente aceitáveis, afinal é o Access que garante seu bom trabalho, e parabéns por isso. Mas o foco que está sendo discutido, e faço questão de amadurecer a discssão, é de como desenvolver uma aplicação dinâmica escrita com Delphi!

[]s
Rubem Rocha
Manaus, AM

Ok!
Deêm uma olhada neste software
http://www.xmaker.com.br/

X-Maker é um gerador de aplicativos em Delphi, voltado para desenvolvedores de software. Utilizando todo potencial da linguagem orientada a objetos, acelera o processo de desenvolvimento de forma extremamanete eficiente, prática e padronizada. Contém um projeto de Exemplo, Ajuda e Tutorial em Flash. Com acesso as base de dados em FireBird e MySql.

Qualquer semelhança com Access é mera coincidência. :twisted:

Eu cheguei a avaliar o X-Maker no ano passado, para necessidade própria, e achei ele bem básico. Mas, em termos de montar um protótipo de um sistema, achei ele de certa forma interessante.

No entanto, ele está bem longe de ser uma ferramenta para aplicações dinâmicas com Delphi. Gerador de código é uma coisa; agora vc ter uma aplicação total ou em grande parte dinâmica, é outra história. Digo isso pq o tipo de informação que usado pelo X-Maker é estático, ou seja, se ele mudar todo o sistema (ou uma parte do mesmo) deverá ser regerada, enquanto que a proposta de uma aplicação dinâmica seria que, ao ocorrer uma mudança, quase nenhuma mudança no sistema seria implicada, uma vez que o núcleo de execução do sistema entenderia a mudança e se adaptaria rapidamente.

[]s
Rubem Rocha
Manaus, AM

Olá a todos,

Aproveitando o assunto sobre qual a melhor ferramenta para se trabalhar desta forma, gostaria de saber se alguém já trabalhou com os componentes:

-JvInterpreterFm
ou
-JvInterpreterProgram

os dois vem com os pacotes JEDI na aba ´Jv Interpreter´.

Pelo que eu testei e estudei sobre esses componentes, eles dão a possibilidade de executar código (PASCAL) em modo de execução...
Seria uma boa opção o uso desses componentes neste filosofia...

Alguém já trabalhou ou trabalha com eles?

Até mais!

Só pra tirar algumas dúvidas: Aqui na empresa que eu trabalho também estamos buscando isso. E detalhe, temos duas referências: o sistema da microsiga, que tem um dicionario de dados ativo, e o M$Access. Sim, isso mesmo, o access, porque?

Se você desconsiderar que o access não é banco de dados e nem suporta uma carga de dados muito grande, prceberá:

1) com ele você cria o seu próprio banco de dados (tabelas, campos, views, relacionamentos, triggers e regras)
2) Você cria suas proprias forms dinamicamente, e elas ficam gravadas no access.
3) Você cria seus próprios relatórios
4) Macros, programação VB embutida
5) Manipulação e vinculação com arquivos externos
6) outros recursos que eu nem conheço.

Ou seja, flexibilidade total. Será que é isso que não estamaos fazendo? não estamos tentando desenvolver um access? Se conseguirmos, porem de um modo que seja facil escolher o tipo de banco de dados (Interbase, firebird, sqlserver, oracle etc) ficaria bem mais seguro e flexível do que o access (logico dã)

Eu tenho certeza que a intenção não é essa. O que, particularmente, se necessita é de uma camada dentro de nossas aplicações que permita interação com qualquer banco de dados, permitindo uma total flexibilização na criação e manutenção dos recursos dispobilizados por elas (formulários, relatórios, regras de negócio, etc.).

Sds.,
Rubem Rocha
Manaus, AM

Alguem conhece o projeto Folha Livre?

Acho que poderia dar um ideia de sistema dinamico.

http://br.groups.yahoo.com/group/folha_livre

não consegui achar um lugar pra baixar uma versão para que eu pudesse ver.. :(

Alguém sabe onde posso baixar?

[]s

http://sourceforge.net/projects/folha-livre

[]´s

Renato

Valeu... :D

gostei da parte de mexer nas fórmulas... muito bom!


[]s

Se vc ver um Sistema com o ERP Microsiga por exemplo verá que boa parte dele e montado dinamicamente, pode não ter uma interface até muito bonita mas é funcional e permite uma boa facilidade de customização.

Precisamos de programadores no projeto folha livre... Participe e divulgue

Pessoal o problema de desenvolver programas ditos dinâmicos, é o desenvolvimento das regras de negócios que é o Tendão de Aquiles. Eu considero como a chave para projetos de sucesso

Acredito que o maior problema deste tipo de aplicação são dois:

1) Como guardar o Dicionário de Dados, para que nao fique lento a leitura.

2) E as validações? como ficam?


Lembrando do amigo acima, a Microsiga tem o sistema totalmente dinamico, e até uma linguagem de programacao para as validacoes e etc...

[]s

1) no protheus (erp da microsiga) a leitura é feita na abertura do sistema. os parâmetros são em tempo real, ou seja, são recuperados do banco sempre que seu valor é solicitado.

2) as validações e gatilhos são feitos com o auxílio de parsers (analisadores de fórmulas). por exemplo: para validar um campo CNPJ é colocado no campo [i:ef9e435fc0]validação[/i:ef9e435fc0] do dicionário de dados algo como [b:ef9e435fc0]ValidaCNPJ( SM0->CNPJ )[/b:ef9e435fc0], assim o analisador de fórmulas executa a função e permite o prosseguimento apenas se o valor é verdadeiro.

isto que eu tento fazer... o incrivel é como eles recuperam o dicionario de dados, é muito rápido!

[]s

Lembre-se: ´uma ideia so é dificil antes de executar. o facil todo mundo faz, o dificil é para quem é bom, o impossivel é para os excepcionais.´

Porque não começamos a desenvolver um projeto juntos assim podemos ir colocando nossas ideias e resolvendo os problemas, acho melhor que ficar aqui falando e pensando nas dificuldades.
Vamos por esta ideia em pratica e acreditar que em programação podemos fazer qualquer coisa

Concordo com você DPinho... estou disposto a ajudar nesta empreitada...

Como eu disse, o maior impecilho para isto é onde ficar o dicionário de dados? Podemos começar por aí, o que acham?

[]s