Autor Tópico: Importação de valores do Banco de dados  (Lida 2595 vezes)

snarkhx

  • Novato
  • *
  • Mensagens: 35
Importação de valores do Banco de dados
« Online: Janeiro 17, 2007, 12:23:03 pm »
Porque o Script Case não importa os valores padrões dos campos registrados no Banco de dados??

Várias informações estão lá por um motivo: pra serem utilizados na aplicação!

Coisas como:
+ chave com autoincremento :: já deveria ser percebida e automaticamente configurada na aplicação formulário
+ campos com opção default já preenchida :: deveriam ser automaticamente configurados na aplicação formulário na parte de atribuição de valores de inclusão;
+ campos enum e set :: Deveriam ser configurados como select e ter as opções de lookup assim: Manual e cada opção seria uma opção da definição do campo.

Já deveriam fazer parte da geração do scriptcase a muito tempo.
Simplificam muito o desenvolvimento.

;-)




Haroldo

  • Expert
  • *****
  • Mensagens: 6268
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re: Importação de valores do Banco de dados
« Responder #1 Online: Janeiro 20, 2007, 12:43:08 am »
minha sugestão para esse tópico foi colocado na comunidade scriptcase no orkut:

23/12/2006 09:24 Sugestão : Dicionário de Dados I
Podemos sugerir funcionalidades de produtos IDE que poderiam ser agregadas ao SC3 ajudando-o a ser realmente produtivo:

Explanar todos os o pontos para melhoria seria atropelar a evoluçào do SC3, mas eu iniciaria por um item que poderia dar uma alavancada extraordinária ao IDE SC3:

DICIONÁRIOS DE DADOS:

Hoje o mesmo só serve para adicionar labels padrões aos campos, mas a verdadeira funcionalidade do DICIoNÁRIO DE DADOS é:

Atribuir propriedades aos campos das tabelas a serem reaproveitados em qualquer aplicação de qualquer projeto como:
CAMPOS->
.Label Longo (Form)/Label Curto(grid)
.Caixa Alta, Caixa Baixa, Capitula Primeira ou Todas
.Quantidades de digitos Max/Min
.Tamanho da janela objeto em form
.requerido ou não
.tipo (texto, check Box)
.metodos aplicados nos evento
.Validate_metodo (se retornar diferente de 0 não validar o campo)
.Range (valor inicial e final permitido)
.mascaras (melhorar o engine de mascara: tipo numerico ou ascii) se numérica (000.000,00 ou ZZZ.ZZ0,00) , padrões (cnpj ou cpf, telefone com 0800 ajustando a direita, etc...)
.Campo, tabela de relacionamento com lookup automático (escolher o tipo de lookup com itens staticos ou dinamicos (de outra tabela)
.AutoFind (Se o focus estiver nesse campo a navegação se da por ele)
.DisplayOnly
.Valor padrão na inclusão doregistro caso o campo não seja alterado
.help Status mostrando no rodapé do Menu, uma explicação do campo dinamicamente -> sempre que o campo receber o focus

TABELA->
Procedures UPDATE, DELETE, CREATING, BACKOUT (assim que o registro é lido)
Funções: Validate_Save (sempre na inclusão alteração), Validate_delete (Sempre na deleção)
Controle Deleção de registros filhos de outra tabela relacionada (sim ou não)       excluir   
 
 
CentralSys  23/12/2006 09:25 Dicionário de Dados II
Na estrutura do scriptcase teria uma pasta ex: DDSRC (dataDictinary Source) com subpastas com o nome dos banco de dados e dentro destas pastas arquivos com essas definiçoes ex: nomedatabela_DD.inc.

E sempre na utilização dessa tabela ao selecionar o campo trazer por padrão todas as propriedades dos campos e gravar na aplicação, caso desejamos alterar uma propriedade ou outra de uma determinado campo numa especifica aplicação poderiamos fazer.

Isso traria um aumento na produtividade de desenvolvimento substãncial. Imaginem nãorpecisar ficar repetindo os mesmos passos para sempre qure formos utilizaro mesmo campo de uma tabela em várias aplicações??? 40% de nosso tempo seria na construção do dicionário de dados, mas ao desenvolver a aplicação praticamente sairia pronta.

Assim que possivel estarei dispondo outras sugestões aqui.
Abraços a todos,

 
 
CentralSys  23/12/2006 13:18 Crítica - SC3 e Normalização ISO9000
O ScriptCase tem algumas deficiências quanto a normas do ISO9000 para software, e uam delas é a redundância de dados, informações:

Exemplo: Nas aplicações publicadas, a pasta img fica dentro de cada pasta de aplição, com uma cópia de todas as imagens que se repetem em cada pasta ig de cada aplicação.

Na publicação o SC poderia perguntar se desejamos usar uma pasta padrão para imagens, e solicitar a partir do raiz do site (não a url completa como pede em vários pontos do IDE), um pasta padrãode imagens, fica por conta do desenvolvedor se quer uma pasta padrão ou um apasta em cada pasta de apllicação.