Tornar o Scriptcase algo realmente comparável a ferramentas altamente produtivas

Comparar hoje o SCriptcase V3 com um aplicação IDE Desktop produtiva, é exagerar um pouco, podemos dizer que para desenvolver aplicativos para web, aí sim o SC3 tem vantagens sobre outros produtos.

Mas queremos que o SC3 seja também um aplicativo desktop de alto produtividade.

Segue aqui sugestões para transformar o SC3 e uma verdadeira ferramenta de desenvolvimento.

2 Curtidas

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)

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,

Haroldo Passos

3 Curtidas

Essa sugestão aqui ainda está de pé.

3 Curtidas

Visualizando a postagem, creio que a maioria, se não todas as sugestões já são realidade no produto. Poderia elaborar melhor as funcionalidades listadas aqui que você considera ausentes?

1 Curtida

Sério mesmo?
Leia com mais antenção o tópico de 2006.

O assunto trata-se de Dicionário de Dados.

O DD do SC tem os recursos expostos acima?

Me apresente você no Dicionário de Dados do Scriptcase os recursos sugeridos aqui.

Seria bom que no dicionario de dados pudessemos colocar definicoes de lookup para campos select, pois é muito chato ter que ficar repetindo a mesma coisa em cada formulario que usa o mesmo select.
Que os formularios grid editavel pudessem gravar automaticamente sem a necessidade de usar o mouse.

É o que quis dizer com métodos no evento.

Essa sugestão ainda permanece

TAGS: HAROLDO, SUGESTÃO, DICIONÁRIO DE DADOS

2 Curtidas