[Blake-devel] =?ISO-8859-1?Q?Re=3A_=5BBlake-devel=5D_=5BBlake-devel=5D_-?= =?ISO-8859-1?Q?_Mapeamento_de_opera=E7=F5es?=

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

lscheidegger - xdev wrote:

> Ao mapear as interfaces e operações, nós temos que ter em conta que
> teremos uma situação padrão definida para cada uma delas.

Ok, mas como vc definiria a situacao padrao para a adicao de um objeto, 
por exemplo? IMHO, isto é impossivel - voce nao consegue determinar, de 
forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha 
informacoes sobre o pai dele, existem diversos casos onde vc nao quer 
adicionar o objeto a um só pai (por exemplo, fazer um determinado 
usuário pertencer a vários grupos).

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 
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 
ter em mente eh:

- Usuario navega pela aplicacao
- Usuario seleciona uma operacao
- Se a operacao precisar de dados para funcionar:
   - Form apresentado pro usuario
   - Usuario preenche dados, pressiona submit
   - Dados sao validados
     - Se a validacao ocorreu sem problemas:
       - Executar a operacao
       - Redirecionar o usuario a uma tela com resultados
     - Se a validacao apontou inconsistencias:
       - Re-exibir o formulario, com os dados e dicas de como corrigi-lo
- Se a operacao puder ser executada sem input:
   - Executar a operacao
   - Redirecionar o usuario a uma tela com resultados

Faltou alguma coisa aqui?

> O que fazemos normalmente é criar uma definição padrão para cada
> interface, operação e propriedade, e mesclamos apenas as diferenças que
> a entidade/classe que está sendo processada tem.

O problema de fazer isso eh que vc engessa demais a coisa - eu já 
consigo ver usuarios do Blake se perguntando "putz, eu sei que dá pra 
fazer isso, mas eu não faco a menor idéia de como... acho que eu vou ter 
que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso 
  - eu quero que todo o processo de criacao de uma aplicacao com o Blake 
seja extremamente aberto, e customizavel.

> Alguns pontos:
> 
> - O que o blake possibilitará é criar rapidamente a camada de negócio, a
> camada de negócios 100% das vezes são dados, por mais que vc persista em
> objetos serializados.

A camada de negocios é feita de regras de negócio e dados, onde as 
regras de negócio operam. Usando a API que eu descrevi no outro e-mail, 
nós resolvemos o problema das duas. No seu modelo, a existência das 
regras de negócios está sendo negada. Por isso vc precisa de AOP - pq vc 
   esta deixando de levar em consideracao a outra metade do que é uma 
camada de negocios ;)

> O fato de vc guardar o id do objeto, em detrimento
> do  rowid, ou do campo que é primary key, faz com que vc guarde uma
> referência ao objeto / registro da mesma forma. Em suma, vc sempre terá
> que guardar um indexador.

Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem 
que seja o endereco de memoria onde eles estao. Mas voce precisa saber 
disso quando esta desenvolvendo um formulario de cadastro de clientes? 
Nao, voce nao deve ter que saber disso. Voce precisa de uma primary key? 
Nao - o unico caso onde eu vejo uma PK sendo util em uma aplicacao eh 
evitar a criacao de objetos com campos-chave duplicados, e, 
sinceramente, nao precisamos do peso conceitual e funcional de uma PK 
pra isso.

> - O modelo relacional não é oposto ao orientado a objeto por mais que
> seus livros falem isso, eles são complementares. Principalmente pelo
> fato do modelo orientado a objeto ser extremamente trabalhoso na camada
> de negócios, onde seu reaproveitamento é pífio. Enquanto que no modelo
> que estamos propondo não. 

OO e R nao sao complementares, mas concordo se vc disser que OO eh um 
superset do modelo relacional. No modelo relacional, existem dados e 
relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe 
identidade.

E de onde vc tirou que "fato do modelo orientado a objeto ser 
extremamente trabalhoso na camada de negócios, onde seu reaproveitamento 
é pífio"? Poderia citar exemplos e fatos que comprovem essa afirmacao?

> Não adianta termos tudo orientado a objeto, estado da arte, se temos uma
> dificuldade muito grande de reaproveitar o que já fizemos. 
> -Quem deve e será completamente oop, é o framework.

Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte, 
entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework 
quanto o modelo devem ser OOP - se é que a gente quer fazer algo 
estado-da-arte, como vc mesmo diz.

>>>//indica que a primary key é gerada automaticamente e não pode ser 
>>>alterada
>>>add.hiddenIdentifier(true);
> 
>>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh 
>>coisa do banco de dados - e eu sinceramente nem quero usar um, entao
>>suma com essas nojeiras de modelo relacional da minha frente! :D
> 
> Entenda isso como um indexador. Eu tb quero usar o prevayler, assim como
> quero tb usar o oracle. Cara sinto muito, não podemos condicionar o uso
> do Blake com o uso do Prevayler. 

De onde vc tirou isso?

Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao 
Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs 
é horrivel. Isso deve ser transparente pra ele - ele nao tem que saber 
se o objeto que ele criou vai ser mapeado pra um banco de dados ou pra 
um punhado de objetos serializados (como eh o caso do Prevayler).

...ou por acaso vc nasceu com um ID estampado na testa? No mundo real, 
as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro de 
Pessoa Fisica, um documento, que, obviamente nao eh um ID.


>>>//PROCESS
>>>//define qual é a operação que será chamada após o processamento do 
>>>formulário add.setRedirectOperation("report");
> 
>>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :)
> 
> Se tinha sido mapeado, eu nào entendi onde e como.

Quando eu criei novas Actions, e chamei addAction nas instancias de 
ClassDefinition (usuario e grupo).

>>>//define a query de processamento
>>>add.setQuery("add");
> 
>>Que query? De onde vem esse "add"? Magica?
> 
> Não definição padrão, que o wizard responsável interpretará e procurará
> uma query add, ou qq forma de persistência de dados chamada add. Um dos
> conceitos do XDev, e que mantemos em arquivos separados as
> classes/definições e suas queries, dessa forma para um User.java, tem um
> User.sql. Com relação ao prevayler, teremos que pensar uma alternativa.

Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo. 
Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta 
colocando os _metodos_ do objeto fora dele.

>>>Supondo que essa seja a definição padrão de uma propriedade string:
>>>string.setLenght(100)
>>>string.isMandatory(false)
>>>string.isVisible(true)
>>>string.setCaption("")
>>>string.isIdentifier(false)
> 
>>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim a 
>>gente nao precisa ficar adicionando um >metodo novo na classe Property 
>>sempre que precisar de outro tipo de validacao.
> 
>>Lembrando:
> 
>>objeto.addConstraint("propriedade", new Constraint());
> 
> Esse não é um modelo de constraints, e sim uma definição padrão para uma
> propriedade do tipo string. Ou seja se vc criar uma propriedade string
> em sua entidade, e não informar mais nada, ela terá exatamente essa
> configuração.

De novo, vamos ao debate sobre a "situacao default". Ter uma 
configuração assim nos seus objetos acontecendo por baixo dos panos é 
ruim, pq, afinal, está acontecendo debaixo dos panos.

>>>Essa é a definição padrão de um campo numérico
>>>(...)
>>>
>>>Vamos criar uma entidade Usuário, vou exemplificar apenas a inclusão.
>>>
>>>// Cria a definicao da classe
>>>usuario = new ClassDefinition("Usuario");
>>>
>>>// Cria as propriedades que a classe vai ter 
>>>usuario.addProperty("id", Number.class);
> 
>>AAAAAARGH! :D
> 
> O que está sendo feito aqui é adicionando uma propriedade, com base em
> um template.

Nao. O que esta sendo feito aqui é adicionar uma propriedade que um 
Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome, senha, 
   permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo um 
unico uso pra essa propriedade. Voce poderia me indicar um, que nao seja 
meramente a persistencia?

[]'s
-cv