Scriptcase 9.9 Otimização dos Lookups

ScriptCase Versão 9
#1

Otimização dos Lookups e Dicionário de Dados.

Opinião pessoal minha.

Eu não uso chaves estrangeiras nas minhas tabelas. Todas regras de negócios estão em uma camada do php em classe oop (model) e como formulários apresentam falha nascida com o SC ajax na questão multiusuário geralmente para formulário uso controle (view & control) para interface com usuário.

O que não gostei: A otimização traz automático o campo select, e como sabemos, em tabelas com muitos registros esse tipo de campo trava a página. (Deu ruim NM).

Dicionário de dados: Não uso DD do SC, por achar ele muito aquém do que realmente deve ser um DD, tem tópicos aqui que falo a respeito desde sempre.

A questão dos idiomas também não utilizo, pois para mim a tradução deve ficar em banco de dados e ser aplicada dinamicamente sem precisar gerar o código fonte da app.

Versão nova, black friday, mas a correção dos campos AutoComplete com Select2 não vi ainda.

A intenção foi boa, mas a funcionalidade vem com problemas(Campo do tipo select, bug lendário no select2).

3 x 3 para 9.9

3 Curtidas
#2

Concordo com vc Haroldo.
Na minha humilde opiniao, esse lookup “otimizado” nao otimiza praticamente nada. Em primeiro lugar, isso que vc ja falou, muitas tabelas nao tem chave estrangeira definida. Muitas vezes a gente faz isso via codigo.
Alem disso, quantas vezes a gente cria o mesmo formulario para a a mesmas tabelas? Em geral, a gente so cria um formulario de edicao de uma tabela apenas uma vez. Entao nao ha muito ganho nisso.
O que eu ja sugerir a netmake, foi que eles criassem uma forma de podermos gravar a definicao de campos select em algum lugar. Imagine 30 controles nos quais eu preciso colocar o mesmo campo select. Cada controle vai gerar um relatorio por exemplo. Imagina eu ter que colocar o campo e definir o mesmo select 30 vezes. Dai, em determinado momento eu decido que no campo do nome eu vou fazer um CONCAT ou usar um substring. Lá vou eu em 30 formularios ajustar um a um. É horrivel. Se eu pudesse puxar essa definicao dinamicamente de algum lugar, usando uma macro, ou se nas propriedades do campo select, eu pudesse informar a definicao do dicionario, entao bastaria eu ir num unico lugar e modificar apenas aquela definicao, que automaticamente todos os 30 formularios de controle iriam se adaptar. Enfim, a gente pede uma coisa, eles criam outra completamente diferente e inutil.

2 Curtidas
#3

Amigo Haroldo
Gostaria de pedir maiores explicacoes sobre alguns pontos do seu comentario.
Voce poderia explicar melhor como vc coloca as regras de negocio nessa camada php?
No caso de usar controle em vez de formularios do SC, porque abrir mão de funcionalidades já prontas e fazer tudo na unha? Nao seria bem mais complicado, principalmente quando uma tabela possui dezenas de campos?

#4

Pegue um formulário, abra-o em dois browsers diferentes.
Selecione o mesmo registro em ambos.
No Browser A, altere um dado de um campo e salve.
No browser B, altere um dado de um campo diferente (do alterado no campo do form do browser A) e salve.
Recarregue o formulário no registro alterado nos 2 browsers, verá que os dados alterados no browser A foram perdidos.

Essa é a questão multiusuário que relatei.

Quanto a manter as regras de negócio em uma camada do php, é uma boa prática (MVC) e posso reutilizar em outros frameworks as mesmas classes. Nessas regras de negócio o update no registro só é executado nos campos que receberam alteração (diferente como um formulário SC faz, que executa o update em todos os campos, independente se recebeu alteração ou não).

2 Curtidas
#5

Digamos que em vez de um form, eu utilize um controle semelhante e abra em 2 browsers diferentes. No A eu altere o campo NOME, e salve. No B eu altere o campo NOME, e salve. Ao recarregar os browsers, ambos terão a alteracao feita pelo borwser B. Nao seria a mesma coisa?

Ainda, com relacao a classe, poderia nos apresentar um exemplo bem simples de como utiliza-la? Ela seria definida numa blank? Numa biblioteca interna ou externa?

#6

Aí é meio lógico a última alteração no mesmo campo prevalece.
Mas na controle eu tenho o controle da gravação.
No formulário se forem campos diferentes as alterações de quem salvou primeiro são perdidas.

Minhas classes estão todas em bibliotecas externas.

Vamos ver se NM melhora essa questão do formulário (espero isso desde 2006), caso contrário eu posso sim fazer uma demonstração.

4 Curtidas
#7

Haroldo, muito boas as suas colocações. Você fez referência a camada de regras de negócio em PHP-OOP. Relacionado a banco de dados, você usa ORM? ORM desenvolvido por você ou algum framework de terceiros? Deixe-nos conhecer mais da sua experiência.

#8

Eu desenvolvo todos meus códigos, não uso FW de terceiros.

#9

Não uso a ultima versão, meu scriptcase ainda é o pé duro. Mas esse tipo de controle para multi-usuário, precisei fazer uma implementação a parte. Quando dois usuários alteram o mesmo registro, aparece uma no alerta de validação a mensagem de que o registro já foi alterado por outro usuário.