[Blake-devel] =?iso-8859-1?Q?RES:_=5BBlake-devel=5D-_Mapeamento_de_opera=E7=F5es?=

[Rafael S. <ra...@in...>]

	Olha,=20


-----Mensagem original-----
De: bla...@li...
[mailto:bla...@li...] Em nome de Carlos
Villela
Enviada em: quarta-feira, 20 de agosto de 2003 16:22
Para: bla...@li...
Assunto: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de
opera=E7=F5es


> Acho que se a gente quer fazer um framework que seja, de fato, util em

> todos os casos, nao podemos nos prender a criar "situacoes default",
pq=20
> estas situacoes variam de projeto pra projeto, e de modelo pra modelo,

> principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da

> pra encaixar 100% dos casos. A *unica* situacao default que a gente
pode=20
> ter em mente eh:

para GRANDE parte dos casos eh possivel criar situacoes padrao, que sao
simplesmemte inserir dados, deletar, fazer select etc etc.. situacoes
como "insira o registro do usuario, pegue entao o id gerado e adicione
este id na tabela de grupos, relacionando com x, y e z" sao excecoes a
regra, que nao acontecem todo o tempo.=20
Por isso que eh preciso ter bem definida a parte de funcionamento para
quando tais excecoes forem necessarias. Por exemplo: no Oracle bastaria
simplesmente fazer uma procedure e disparar algum trigger ( ou fazer
tudo na procedure mesmo ).. Se estivesse usando MySQL, teria que fazer
queries diferentes, fazer codigo para isso ( execute a query, salve o id
em uma variavel e execute esta outra query ).

O sistema precisa suportar esse tipo de coisa, como voce mesmo citou. A
implementacao atual do xdev nos da limitacoes sim, em muitos casos
precisamos redirecionar o processamento para codigo da entidade ( quando
eh algo muito em especifico ).
Veja, nao eh gambiarra, eh uma opcao que temos ( "processe isso com as
funcionaliaddes do framework, mas esta outra parque, que nada tem a ver
com o core, voce precisa com o metdo Y da classe X"). Funciona, e nao eh
gambiarra.=20

Porem, concordo *totalmente* contigo em muitos pontos, principalmente na
parte de que o cara vai sair fazendo gambiarra quando estiver "sem
prazo". Por isso, gostaria de saber qual eh a tua sugestao de solucao
para este casos especificos. Ate agora foi mostrado como o Inectis
trabalha, como o XDev trabalha, varios conflitos de interesses, mas
nenhuma coisa definitiva ainda.=20

Carlos, um dos pontos fortes do Blake eh que ele "adivinha" as coisas,
ja que tudo tem uma regra bem definida. Por exemplo, o lance do
mapeamento User.java -> User.sql . Considere a seguinte URL:

host?entidade=3DUser&operacao=3Dreport

com base nisso, o que - atualmente - o blake/xdev faz: pega a entidade
"User", le a definicao dela e tudo mais. Entao vai la e *por default*
procura por um arquivo chamado "User.sql". Veja, o *default* eh isso,
mas se o arquivo se chamar *ABCDE.sql", basta dizer na especificacao que
o arquivo eh esse, sem complicacao. Ja o nome da query se chamar
"report" eh uma regra, mas nada impede de tambem especificar qual query
deve ser executada.=20

A parte de "definicao padrao para cada entidade" parece estar dando uma
certa confusao: o que estamos querendo dizer com "default" sao as
propriedades gerais. Por exemplo, considere as seguintes propriedades:

-> User
nome
email
idade
cidade
telefone
cpf

Digamos que, para todas as propriedades, elas sao visiveis por padrao.
Agora, se no report voce desejar mostrar apenas o nome, email e cpf,
voce vai na parte de definicao do report e diz que telefone, cidade e
idade nao vao ser visiveis ao usuario. Soh isso.=20
Agora, se vc precisar atualizar os dados, o que voce precisa? primeiro,
o cara clica em "editar", e entao vai ser dado um "SELECT * FROM User
WHERE id =3D ?" .. Isso logicamente nao eh coisa do blake, qualquer
sistema que use banco de dados faz isso. Na hora de atualizar os dados,
eh dado um "UPDATE xxxx", certo? Isso o blake faz sozinho, vc nao
precisa configurar nada alem da entidade.=20

Agora, digamos que estivessemos usando MySQL e que fosse necessario dar
update em umas 3 tabelas quando editar o usuario. Como o mysql nao tem
procedures, nem trigger nem nada, como fica o caso? sentamos e choramos?
nao, nos dizemod que, para a operacao de update, um metodo especial deve
ser chamado ( sim, precisamos codar este metodo a parte do framework ).=20


O que eu gostaria de saber eh o seguinte: qual a tua sugestao para o
funcionamento disso? como funcionaria toda essa parte, como o sistema
atuaria, como eh feita a definicao? precisa refazer a definicao toda
hora que precisar de algo? da para mudar somente partes?=20
Veja, gostaria de algo concreto tambem, nao simplesmente "voce faz da
maneira que quiser, pois o sistema eh totalmetne generico".. O que
precisamos - eu, voce, luiz, todo mundo - eh definir de uma vez por
todas como vai ficar a parte de definicao de interface, de operacoes etc
etc... Como as nossas ideias se encaixam nas suas - e vice-versa.=20

Como voce mesmo disse, temos que fazer algo que seja simples para o
usuario final usar, rapido de configurar e flexivel. Quais as tuas
sugestoes? :)

Rafael