[Blake-devel] =?ISO-8859-1?Q?Re=3A_=5BBlake-devel=5D_RES=3A_=5BBlake-dev?= =?ISO-8859-1?Q?el=5D-_Mapeamento_de_opera=E7=F5es?=

[Carlos V. <ca...@bl...>]

> 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. 

Opa, concordo - a gente pode resolver grande parte dos casos usando 
Actions padrao. O que eu tou chiando aqui é que, se a gente esconde isso 
do usuário, o blake vira só mais um monte de pó de pirlimpimpim inútil. 
Se for pra usar alguma coisa default, o usuário *deve, explicitamente*, 
escolher usar o default. É como assinar um contrato, dizendo "sim, eu 
sei o que os defaults fazem, e é exatamente isso que eu quero". Caso 
contrario, é só o cara esquecer de declarar uma Action pra alguma 
operacao, e a coisa toda fica parecendo passe de magica.

> 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 ).

Exatamente. Mas ficar pensando na base de dados nao vai ajudar aqui! Até 
EJBs CMP abstraem a base de dados pro usuário de uma certa forma, então 
pq a gente vai ter que se preocupar com ela aqui? ;)

O que a gente tem que se focar sobre esse assunto é: como fazer o 
mapeamento das entidades pra um modelo de trabalho que, quando os 
objetos forem estupr...err, mapeados, pra uma base de dados, continuem 
transparentes pro usuario. O usuario do Blake nao tem que saber se ele 
foi deployado num Oracle, MySQL ou Prevayler. Ele só quer que a merda do 
formulario que ele tá criando apareca na tela, e que quando alguem 
digitar uma coisa nele e salvar, os dados fiquem seguros em algum lugar.

> 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. 

Legal - nao acho que isso seja gambiarra, alias, eu achei ate bem 
elegante. Mas, vai aqui de novo a minha recomendacao de que todas as 
coisas "default" tem que ser explicitamente selecionadas, e nao só 
usadas assim pq o usuario esqueceu de configurar ;)

> 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.

Entao, o que vcs acharam de usar JavaScript ou outra linguagem de script 
pra que o usuario codifique estas excecoes? Eu achei uma boa sacada, pq 
essas linguagens, alem de nao precisar compilar, ainda tem a vantagem de 
ter profissionais baratos no mercado. Pra mim, no caso das actions, 
especificamente, os casos bizarros sao mto mais comuns do que os casos 
"default". Com os defaults, mesmo que nao tenha uma Action ja prontinha 
pra lidar com ele, é coisa de 2 ou 3 linhas resolver usando JS, e coisa 
de +/- 10 a 20 linhas pra resolver os casos mais esquisitos. 
Definitivamente, nao doi os dedos nem mata ninguem ;)

 > Ate agora foi mostrado como o Inectis
> trabalha, como o XDev trabalha, varios conflitos de interesses, mas
> nenhuma coisa definitiva ainda. 

Tenha calma... a gente ta juntando as ideias ainda, e elas sao bem 
diferentes. Ate chegar a hora do "então tá bom pra todo mundo", ainda 
vai um tempinho :)

> 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=User&operacao=report
> 
> 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. 

Po, outra duvida: o que vai dentro desse User.sql? Se eu entendi bem ate 
agora, a gente nao tem a menor necessidade por isso, ja que a gente pode 
fazer todo o mapeamento sem fazer o coitado do usuario se enlamear todo 
com SQL, nao?

> 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. 

Legal, disso eu gostei, mas, de novo, vai aqui minha enchecao de saco 
sobre coisas default ;)

> (..)

> 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? 
> 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. 

Glad you asked ;)

Bom, as minhas sugestoes, ate agora, sao:

- Fazer com que o usuario use apenas uma linguagem, apenas um conceito, 
apenas um paradigma. Que seja OOP (que eu prefiro), relacional, AOP (que 
eu tambem adoro, mas nao eh a salvacao da lavoura nesse caso), mas que 
seja um soh, pra nao ter aquela confusao de "uhhh, cadeira tem ID? eu 
vou ter que criar um objeto chamado CadeirasMesa?" e por ai vai :o)

- Antes de pensar em usar QDox, XML, uma GUI ou o que quer que seja, 
vamos definir uma API. Assim, de cara, a gente ja consegue identificar o 
core do blake e o resto (as UIs).

- Usar um modelo de constraints nas propriedades bem flexivel, para que 
seja, ao mesmo tempo, dar aos usuarios um conjunto com as constraints 
mais usadas (StringLength, Integer, Required, etc), e dar uma API mais 
facil ainda pra criar novas constraints e validacoes. Ia ser *do 
caralho* bolar um esquema que permitisse validacoes client-side tambem. 
Dá? :)

> 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? :)

Bom, as que eu consegui me lembrar ate agora (pega leve, eu tou sem 
dormir faz dias :D) eu coloquei ai em cima. Tenho certeza que mais 
sugestoes pipocaram nesses ultimos mails que eu mandei, mas sao mais 
sutis, entao eu acabei nao pegando quando os li de novo pra responder 
aqui. Se alguem notou alguma coisa legal que queria acrescentar, fique a 
vontade! :D

BTW, gostei bastante da sua atitude aqui, Rafael - serviu pra mim como 
um "caralho, para de negar tudo que o Luiz fala e faz alguma coisa, 
porra!". Eu sei que nao foi essa a intencao, mas serviu seu proposito ;)

[]'s
-cv