Menu
▾
▴
blake-devel
|
From: lscheidegger - x. <lsc...@xd...> - 2003-08-20 14:13:37
|
S=F3 mudei o subject, porque o subject j=E1 mudou faz tempo :)
Bom carlos, acho que vc n=E3o entendeu muito o que estava propondo, o
principal do outro e-mail era:
Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em conta =
que
teremos uma situa=E7=E3o padr=E3o definida para cada uma delas.
O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para cada
interface, opera=E7=E3o e propriedade, e mesclamos apenas as =
diferen=E7as que
a entidade/classe que est=E1 sendo processada tem.
Supondo que a defini=E7=E3o padr=E3o da opera=E7=E3o add seja (seguindo =
seu
padr=E3o):
[...]
O que estava sendo proposto era menos um formato de c=F3digo, e mais um
conceito.
Esse conceito =E9:
- Vamos mapear tipos de propriedades e tipos de opera=E7=E3o
(link+display+process), como templates.
- Depois disso vinculamos essas propriedades e opera=E7=F5es mapeadas as
classes da camada de neg=F3cio.
Alguns pontos:
- O que o blake possibilitar=E1 =E9 criar rapidamente a camada de =
neg=F3cio, a
camada de neg=F3cios 100% das vezes s=E3o dados, por mais que vc =
persista em
objetos serializados. O fato de vc guardar o id do objeto, em detrimento
do rowid, ou do campo que =E9 primary key, faz com que vc guarde uma
refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre =
ter=E1
que guardar um indexador.
- O modelo relacional n=E3o =E9 oposto ao orientado a objeto por mais =
que
seus livros falem isso, eles s=E3o complementares. Principalmente pelo
fato do modelo orientado a objeto ser extremamente trabalhoso na camada
de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. Enquanto que no =
modelo
que estamos propondo n=E3o.=20
N=E3o adianta termos tudo orientado a objeto, estado da arte, se temos =
uma
dificuldade muito grande de reaproveitar o que j=E1 fizemos.=20
-Quem deve e ser=E1 completamente oop, =E9 o framework.
O resto comentarei no pr=F3prio c=F3digo
>>Desvantagens:
>>- Tem alguma? Me avisem. ;)
>>
>> S=F3 uma, vc escreve pra diabo.
>E voces nao ne?! :D
Na verdade n=E3o, porque o c=F3digo seria s=F3 a v=EDnculo da entidade =
com suas
propriedades e m=E9todos.
/// ESSE PEDA=C7O DE C=D3DIGO SE REFERE A UMA DEFINI=C7=C3O PADR=C3O DE =
UMA
OPERA=C7=C3O N=C3O VINCULADA A NENHUMA ENTIDADE
>> //LINK
>> //define a imagem que aparecer=E1 no bot=E3o=20
>> add.setImage("bt_inclusao.gif");
>
>> //LINK + DISPLAY
>> //Define o caption do link, bem como o t=EDtulo da p=E1gina=20
>> add.setTitle("Inclus=E3o");
>
>> //DISPLAY
>> //define que por default ser=E3o mostrados todas as propriedades no=20
>> formul=E1rio add.getAllProperties(true);
>> //indica que a primary key =E9 gerada automaticamente e n=E3o pode =
ser=20
>>alterada
>>add.hiddenIdentifier(true);
>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh=20
>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=E3o podemos condicionar o =
uso
do Blake com o uso do prevayler.=20
>> //defini=E7=E3o de subt=EDtulo
>> add.setSubtitle("");
>Po, se vc nao vai setar o subtitulo, nao chame o metodo ;)
S=F3 pus isso ai, para mostrar que existe a possibilidade de setar um
subt=EDtulo
>> //PROCESS
>> //define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o =
processamento do=20
>> formul=E1rio add.setRedirectOperation("report");
>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :)
Se tinha sido mapeado, eu n=E0o entendi onde e como.
>> //define a query de processamento
>> add.setQuery("add");
>Que query? De onde vem esse "add"? Magica?
N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel interpretar=E1 =
e procurar=E1
uma query add, ou qq forma de persist=EAncia de dados chamada add. Um =
dos
conceitos do XDev, e que mantemos em arquivos separados as
classes/defini=E7=F5es e suas queries, dessa forma para um User.java, =
tem um
User.sql. Com rela=E7=E3o ao prevayler, teremos que pensar uma =
alternativa.
>> //define se h=E1 algum m=E9todo de valida=E7=E3o que deva ser chamado =
antes=20
>> da inclus=E3o
>>add.setValidationMethod("validate");
>"validate" o que? Como? O que acontece quando a validacao falha?
Supondo que vc precise de um valida=E7=E3o server-side bem espec=EDfica, =
ap=F3s
um processamento, como propriedades unique em databases que n=E3o tem =
esse
tipo de constraint, vc pode por reflection chamar o m=E9todo que vc
indicou nessa fun=E7=E3o, esse m=E9todo far=E1 as consist=EAncias =
necess=E1rio,
gerando um erro, ou retornando true.
>> Supondo que essa seja a defini=E7=E3o padr=E3o 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=20
>gente nao precisa ficar adicionando um >metodo novo na classe Property=20
>sempre que precisar de outro tipo de validacao.
>Lembrando:
>objeto.addConstraint("propriedade", new Constraint());
Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o =
padr=E3o para uma
propriedade do tipo string. Ou seja se vc criar uma propriedade string
em sua entidade, e n=E3o informar mais nada, ela ter=E1 exatamente essa
configura=E7=E3o.
>> Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico
>> (...)
>>
>> Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a =
inclus=E3o.
>>
>> // Cria a definicao da classe
>> usuario =3D new ClassDefinition("Usuario");
>>
>> // Cria as propriedades que a classe vai ter=20
>> usuario.addProperty("id", Number.class);
>AAAAAARGH! :D
O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com base =
em
um template.
>> usuario.addProperty("nome", String.class);
>>
>> //define que o campo id =E9 chave prim=E1rio, e que seu valor vem de =
uma=20
>> seguence ou campo auto_increment=20
>> usuario.properties.get("id").isIdentifier(true);
>> usuario.properties.get("id").setType("sequencer");
>AAAAAAAAAAAAAAAARGH!!! :D
Idem.
>> //define a legenda da propriedade nome=20
>> usuario.properties.get("nome").setCaption("Nome do Usu=E1rio");
>Hmm, nao gostei - a internacionalizacao vai pro saco se vc fizer isso=20
>;)
Isso pode facilmente ser resolvido, n=E3o?
>> //addAction (String type,boolean automatic=3Dtrue)=20
>> usuario.addAction("add");
>De novo, qual eh a magica que ta acontecendo aqui?
Vc est=E1 vinculando um template de opera=E7=E3o a uma entidade.
[]'s
Luiz
|
|
From: Carlos V. <ca...@bl...> - 2003-08-20 19:37:11
|
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
|
|
From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 00:33:07
|
Acho que est=E1 na hora de separarmos as discuss=F5es. De outra forma =
cada
e-mail ser=E1 um livro =E9 uma queda de bra=E7os em v=E1rias frentes.
1=BA Como ser=E3o definidas as opera=E7=F5es e propriedades;
2=BA Qual ser=E1 a abrang=EAncia do Blake;
3=BA Como faremos persist=EAncia de dados, como relacionaremos registros =
x
objetos;
4=BA Como e quanto das interfaces ser=E3o mapeadas;
Responderei cada quest=E3o em um e-mail
At=E9
-----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
lscheidegger - xdev wrote:
> Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em conta =
que=20
> teremos uma situa=E7=E3o padr=E3o definida para cada uma delas.
Ok, mas como vc definiria a situacao padrao para a adicao de um objeto,=20
por exemplo? IMHO, isto =E9 impossivel - voce nao consegue determinar, =
de=20
forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha=20
informacoes sobre o pai dele, existem diversos casos onde vc nao quer=20
adicionar o objeto a um s=F3 pai (por exemplo, fazer um determinado=20
usu=E1rio pertencer a v=E1rios grupos).
Acho que se a gente quer fazer um framework que seja, de fato, util em=20
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,=20
principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da=20
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 =E9 criar uma defini=E7=E3o padr=E3o para =
cada=20
> interface, opera=E7=E3o e propriedade, e mesclamos apenas as =
diferen=E7as=20
> que a entidade/classe que est=E1 sendo processada tem.
O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20
consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 pra=20
fazer isso, mas eu n=E3o faco a menor id=E9ia 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:
>=20
> - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de =
neg=F3cio,
> a camada de neg=F3cios 100% das vezes s=E3o dados, por mais que vc=20
> persista em objetos serializados.
A camada de negocios =E9 feita de regras de neg=F3cio e dados, onde as=20
regras de neg=F3cio operam. Usando a API que eu descrevi no outro =
e-mail,=20
n=F3s resolvemos o problema das duas. No seu modelo, a exist=EAncia das=20
regras de neg=F3cios est=E1 sendo negada. Por isso vc precisa de AOP - =
pq vc
esta deixando de levar em consideracao a outra metade do que =E9 uma=20
camada de negocios ;)
> O fato de vc guardar o id do objeto, em detrimento
> do rowid, ou do campo que =E9 primary key, faz com que vc guarde uma=20
> refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre=20
> ter=E1 que guardar um indexador.
Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem=20
que seja o endereco de memoria onde eles estao. Mas voce precisa saber=20
disso quando esta desenvolvendo um formulario de cadastro de clientes?=20
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=20
evitar a criacao de objetos com campos-chave duplicados, e,=20
sinceramente, nao precisamos do peso conceitual e funcional de uma PK=20
pra isso.
> - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por mais =
que=20
> seus livros falem isso, eles s=E3o complementares. Principalmente pelo =
> fato do modelo orientado a objeto ser extremamente trabalhoso na=20
> camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. Enquanto =
que no
> modelo que estamos propondo n=E3o.
OO e R nao sao complementares, mas concordo se vc disser que OO eh um=20
superset do modelo relacional. No modelo relacional, existem dados e=20
relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe=20
identidade.
E de onde vc tirou que "fato do modelo orientado a objeto ser=20
extremamente trabalhoso na camada de neg=F3cios, onde seu =
reaproveitamento
=E9 p=EDfio"? Poderia citar exemplos e fatos que comprovem essa =
afirmacao?
> N=E3o adianta termos tudo orientado a objeto, estado da arte, se temos =
> uma dificuldade muito grande de reaproveitar o que j=E1 fizemos. -Quem =
> deve e ser=E1 completamente oop, =E9 o framework.
Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte,=20
entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework=20
quanto o modelo devem ser OOP - se =E9 que a gente quer fazer algo=20
estado-da-arte, como vc mesmo diz.
>>>//indica que a primary key =E9 gerada automaticamente e n=E3o pode =
ser
>>>alterada
>>>add.hiddenIdentifier(true);
>=20
>>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
>=20
> Entenda isso como um indexador. Eu tb quero usar o prevayler, assim=20
> como quero tb usar o oracle. Cara sinto muito, n=E3o 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=20
Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs=20
=E9 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=20
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,=20
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 =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o =
processamento do
>>>formul=E1rio add.setRedirectOperation("report");
>=20
>>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :)
>=20
> Se tinha sido mapeado, eu n=E0o entendi onde e como.
Quando eu criei novas Actions, e chamei addAction nas instancias de=20
ClassDefinition (usuario e grupo).
>>>//define a query de processamento
>>>add.setQuery("add");
>=20
>>Que query? De onde vem esse "add"? Magica?
>=20
> N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel =
interpretar=E1 e=20
> procurar=E1 uma query add, ou qq forma de persist=EAncia de dados =
chamada=20
> add. Um dos conceitos do XDev, e que mantemos em arquivos separados as
> classes/defini=E7=F5es e suas queries, dessa forma para um User.java, =
tem=20
> um User.sql. Com rela=E7=E3o ao prevayler, teremos que pensar uma=20
> alternativa.
Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.=20
Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta=20
colocando os _metodos_ do objeto fora dele.
>>>Supondo que essa seja a defini=E7=E3o padr=E3o de uma propriedade =
string:
>>>string.setLenght(100)
>>>string.isMandatory(false)
>>>string.isVisible(true)
>>>string.setCaption("")
>>>string.isIdentifier(false)
>=20
>>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.
>=20
>>Lembrando:
>=20
>>objeto.addConstraint("propriedade", new Constraint());
>=20
> Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o =
padr=E3o para=20
> uma propriedade do tipo string. Ou seja se vc criar uma propriedade=20
> string em sua entidade, e n=E3o informar mais nada, ela ter=E1 =
exatamente=20
> essa configura=E7=E3o.
De novo, vamos ao debate sobre a "situacao default". Ter uma=20
configura=E7=E3o assim nos seus objetos acontecendo por baixo dos panos =
=E9=20
ruim, pq, afinal, est=E1 acontecendo debaixo dos panos.
>>>Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico
>>>(...)
>>>
>>>Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a =
inclus=E3o.
>>>
>>>// Cria a definicao da classe
>>>usuario =3D new ClassDefinition("Usuario");
>>>
>>>// Cria as propriedades que a classe vai ter
>>>usuario.addProperty("id", Number.class);
>=20
>>AAAAAARGH! :D
>=20
> O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com =
base em
> um template.
Nao. O que esta sendo feito aqui =E9 adicionar uma propriedade que um=20
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
-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=3D104
_______________________________________________
Blake-devel mailing list
Bla...@li...
https://lists.sourceforge.net/lists/listinfo/blake-devel
|
|
From: Guilherme S. <gui...@gu...> - 2003-08-21 02:46:48
|
Perguntas: 1. Cade os diagramas e os use cases do projeto? Ou ainda nao tem? Ou a metodologia vai ser "vamu fazendo"...? Sei que eh pesado, nao sei qual a experiencia de cada um com uml e coisa e tal, mas pq nao comecar de um jeito mais organizadinho? 2. Alguem ja viu o produto da apyon? http://www.apyon.com.br/apm/index.htm Existem outros produtos do genero... me falaram que o da apyon ja gera tudo o que agente ta querendo... Guilherme ----- Original Message ----- From: "Carlos Villela" <ca...@bl...> To: <bla...@li...> Sent: Wednesday, August 20, 2003 4:21 PM Subject: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de operações > > > 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 > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > _______________________________________________ > Blake-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blake-devel > |
|
From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 13:12:23
|
1. N=E3o, a metodologia n=E3o =E9 vamu fazendo pois o Blake ser=E1 = apenas o 4 framework que implementa a metodologia, estamos discutindo o que ser=E1 = do Blake, que nada mais =E9 do que uma implementa=E7=E3o da metodologia. = Acho mais do que v=E1lido documentarmos em todo formato uml poss=EDvel, = ali=E1s acho interessante gerarmos os use cases qdo terminamos essa discuss=E3o = de features. 2. Sim,j=E1 vi. A diferen=E7a =E9 que eles geram efetivamente c=F3digo = nativo da linguagem que vc escolher, eu nunca consegui um demo ou nada parecido deles, mas tenho bastante curiosidade de conhece-los. Tem um detalhe, tudo deles =E9 propriet=E1rio. []'s Luiz -----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de Guilherme Silveira Enviada em: quarta-feira, 20 de agosto de 2003 17:44 Para: bla...@li... Assunto: [Blake-devel] Metodologia? Perguntas: 1. Cade os diagramas e os use cases do projeto? Ou ainda nao tem? Ou a metodologia vai ser "vamu fazendo"...? Sei que eh pesado, nao sei qual a experiencia de cada um com uml e coisa e tal, mas pq nao comecar de um jeito mais organizadinho? 2. Alguem ja viu o produto da apyon? http://www.apyon.com.br/apm/index.htm Existem outros produtos do genero... me falaram que o da apyon ja gera tudo o que agente ta querendo... Guilherme ----- Original Message ----- From: "Carlos Villela" <ca...@bl...> To: <bla...@li...> Sent: Wednesday, August 20, 2003 4:21 PM Subject: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de opera=E7=F5es > > > lscheidegger - xdev wrote: > > > Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em = conta que=20 > > teremos uma situa=E7=E3o padr=E3o definida para cada uma delas. > > Ok, mas como vc definiria a situacao padrao para a adicao de um=20 > objeto, por exemplo? IMHO, isto =E9 impossivel - voce nao consegue=20 > 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=F3 pai (por exemplo, fazer um=20 > determinado usu=E1rio pertencer a v=E1rios 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",=20 > pq estas situacoes variam de projeto pra projeto, e de modelo pra=20 > modelo, principalmente, e mesmo sendo absurdamente customizaveis,=20 > ainda nao da pra encaixar 100% dos casos. A *unica* situacao default=20 > 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=20 > 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 =E9 criar uma defini=E7=E3o padr=E3o para = cada=20 > > interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as=20 > > que a entidade/classe que est=E1 sendo processada tem. > > O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20 > consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 = pra=20 > fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu = vou=20 > 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=20 > Blake seja extremamente aberto, e customizavel. > > > Alguns pontos: > > > > - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de=20 > > neg=F3cio, a camada de neg=F3cios 100% das vezes s=E3o dados, por = mais que > > vc persista em objetos serializados. > > A camada de negocios =E9 feita de regras de neg=F3cio e dados, onde as = > regras de neg=F3cio operam. Usando a API que eu descrevi no outro=20 > e-mail, n=F3s resolvemos o problema das duas. No seu modelo, a=20 > exist=EAncia das regras de neg=F3cios est=E1 sendo negada. Por isso vc precisa de AOP - pq vc > esta deixando de levar em consideracao a outra metade do que =E9 = uma=20 > camada de negocios ;) > > > O fato de vc guardar o id do objeto, em detrimento > > do rowid, ou do campo que =E9 primary key, faz com que vc guarde = uma=20 > > refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre = > > ter=E1 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=20 > key? Nao - o unico caso onde eu vejo uma PK sendo util em uma=20 > aplicacao eh evitar a criacao de objetos com campos-chave duplicados,=20 > e, sinceramente, nao precisamos do peso conceitual e funcional de uma=20 > PK pra isso. > > > - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por = mais=20 > > que seus livros falem isso, eles s=E3o complementares. = Principalmente=20 > > pelo fato do modelo orientado a objeto ser extremamente trabalhoso=20 > > na camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. = Enquanto=20 > > que no modelo que estamos propondo n=E3o. > > OO e R nao sao complementares, mas concordo se vc disser que OO eh um=20 > superset do modelo relacional. No modelo relacional, existem dados e=20 > relacionamento, mas nao existe polimorfismo, encapsulamento, mas=20 > existe identidade. > > E de onde vc tirou que "fato do modelo orientado a objeto ser=20 > extremamente trabalhoso na camada de neg=F3cios, onde seu=20 > reaproveitamento =E9 p=EDfio"? Poderia citar exemplos e fatos que=20 > comprovem essa afirmacao? > > > N=E3o adianta termos tudo orientado a objeto, estado da arte, se = temos > > uma dificuldade muito grande de reaproveitar o que j=E1 fizemos. = -Quem > > deve e ser=E1 completamente oop, =E9 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=20 > quanto o modelo devem ser OOP - se =E9 que a gente quer fazer algo=20 > estado-da-arte, como vc mesmo diz. > > >>>//indica que a primary key =E9 gerada automaticamente e n=E3o pode = ser=20 > >>>alterada add.hiddenIdentifier(true); > > > >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh=20 > >>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=20 > > como quero tb usar o oracle. Cara sinto muito, n=E3o podemos=20 > > 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=20 > Prevayler. Eu so estou dizendo que fazer com que o usuario lide com=20 > IDs =E9 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=20 > ou pra um punhado de objetos serializados (como eh o caso do=20 > 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=20 > de Pessoa Fisica, um documento, que, obviamente nao eh um ID. > > > >>>//PROCESS > >>>//define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o = processamento do > >>>formul=E1rio add.setRedirectOperation("report"); > > > >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes?=20 > >>:) > > > > Se tinha sido mapeado, eu n=E0o entendi onde e como. > > Quando eu criei novas Actions, e chamei addAction nas instancias de=20 > ClassDefinition (usuario e grupo). > > >>>//define a query de processamento > >>>add.setQuery("add"); > > > >>Que query? De onde vem esse "add"? Magica? > > > > N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel = interpretar=E1 e=20 > > procurar=E1 uma query add, ou qq forma de persist=EAncia de dados=20 > > chamada add. Um dos conceitos do XDev, e que mantemos em arquivos=20 > > separados as classes/defini=E7=F5es e suas queries, dessa forma para = um=20 > > User.java, tem um User.sql. Com rela=E7=E3o ao prevayler, teremos = que=20 > > pensar uma alternativa. > > Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.=20 > Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta=20 > colocando os _metodos_ do objeto fora dele. > > >>>Supondo que essa seja a defini=E7=E3o padr=E3o 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=20 > >>a gente nao precisa ficar adicionando um >metodo novo na classe=20 > >>Property sempre que precisar de outro tipo de validacao. > > > >>Lembrando: > > > >>objeto.addConstraint("propriedade", new Constraint()); > > > > Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o = padr=E3o para > > uma propriedade do tipo string. Ou seja se vc criar uma propriedade=20 > > string em sua entidade, e n=E3o informar mais nada, ela ter=E1=20 > > exatamente essa configura=E7=E3o. > > De novo, vamos ao debate sobre a "situacao default". Ter uma=20 > configura=E7=E3o assim nos seus objetos acontecendo por baixo dos = panos =E9=20 > ruim, pq, afinal, est=E1 acontecendo debaixo dos panos. > > >>>Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico > >>>(...) > >>> > >>>Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a=20 > >>>inclus=E3o. > >>> > >>>// Cria a definicao da classe > >>>usuario =3D new ClassDefinition("Usuario"); > >>> > >>>// Cria as propriedades que a classe vai ter=20 > >>>usuario.addProperty("id", Number.class); > > > >>AAAAAARGH! :D > > > > O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com = base=20 > > em um template. > > Nao. O que esta sendo feito aqui =E9 adicionar uma propriedade que um=20 > 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=20 > um unico uso pra essa propriedade. Voce poderia me indicar um, que nao > seja meramente a persistencia? > > []'s > -cv > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from=20 > the best hiring companies. = http://www.dice.com/index.epl?rel_code=3D104 > _______________________________________________ > Blake-devel mailing list > Bla...@li...=20 > https://lists.sourceforge.net/lists/listinfo/blake-devel > ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=3D104 _______________________________________________ Blake-devel mailing list Bla...@li... https://lists.sourceforge.net/lists/listinfo/blake-devel |
|
From: Rafael S. <ra...@in...> - 2003-08-21 08:03:17
|
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 |
|
From: Carlos V. <ca...@bl...> - 2003-08-22 05:37:16
|
> 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 |
|
From: lscheidegger - x. <lsc...@xd...> - 2003-08-26 16:20:53
|
Ignorem por favor |
|
From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 12:23:16
|
>> O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para = cada=20 >> interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as=20 >> que a entidade/classe que est=E1 sendo processada tem. >O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20 >consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 pra = >fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu = vou ter=20 >que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso=20 > - eu quero que todo o processo de criacao de uma aplicacao com o Blake=20 >seja extremamente aberto, e customizavel. A solu=E7=E3o para essa quest=E3o se refere menos a arquitetura ou api = do Blake, e mais com sua documenta=E7=E3o, principalmente seus quick = starts, HOWTO, e assim por diante. Por mais que tentemos mapear todas as situa=E7=F5es que veremos, sempre haver=E3o particularidades, e concordo que o sistema tem que ser aberto = a permitir tais particularidades, sem que necessariamente o usu=E1rio = tenha que desenvolver quebra galhos. S=F3 que escrever toda a vez a defini=E7=E3o, caracter=EDstica a = caracter=EDstica da opera=E7=E3o ou propriedade, vc s=F3 est=E1 fazendo com que o = usu=E1rio altere o modelo de programa=E7=E3o que ele j=E1 conhe=E7e, sem dar um ganho = t=E3o expressivo de produtividade e qualidade. A ideia de mapear as interfaces, =E9 encontrar o "default", ter um padr=E3o para as = situa=E7=F5es mais cotidianas, e com um grau de abertura razo=E1vel que fa=E7a com que = o usu=E1rio n=E3o tenha que apelar. O default n=E3o =E9 um engessamento, =E9 mais uma defini=E7=E3o padr=E3o = que os wizards seguir=E3o, caso o usu=E1rio n=E3o define as tais = particularidades. Inclusive o usu=E1rio deve poder a qualquer momento, tirar o blake do = modo autom=E1tico para determinada opera=E7=E3o, em qualquer uma das fases da opera=E7=E3o. N=F3s temos dois tipos de situa=E7=E3o: - A autom=E1tica, na qual o framework l=EA as defini=E7=F5es, e essas se = referem apenas a elementos mapeados, e o blake assim far=E1 o processamento todo automaticamente; - A semi-autom=E1tica, blake continua lendo as defini=E7=F5es, s=F3 que redirecionar=E1 o request para a camada de neg=F3cios, quando isso = ocorrer, inverte-se o comportamento, a camada de neg=F3cios acessar=E1 os objetos = do blake. Dessa forma poderemos ter diversos graus de atua=E7=E3o do Blake, sem = que tenhamos que for=E7ar nada, ou que o usu=E1rio precise apelar. O segredo do blake acima de tudo =E9 demonstrar um modelo, que os = usu=E1rios possam extender com facilidade, ou seja, mapear as interfaces e os diversos tipos de content type das propriedades independentemente de que tenhamos deixado implementado. Talvez uma boa solu=E7=E3o da quest=E3o "Default", e deixar isso aberto para que o usu=E1rio defina o que deve = ser default para suas aplica=E7=F5es. |
|
From: lscheidegger - x. <lsc...@xd...> - 2003-08-22 13:27:32
|
>[..] A *unica* situacao default que a gente pode=20
>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?
Temos muito mais opera=E7=F5es e interfaces na web do que o tradicional
input/output. Form/report
Mas como j=E1 chegamos a conclus=E3o podemos ir mapeando tudo aos =
poucos.
Eu resumiria o que vc est=E1 falando com:
Link=3D>Display=3D>Processamento(opcional).
Exemplo intranet:
- home
- menu (display)
- lista de ramais (link 1 );
- classificados (link 2);
- aniversariantes (link 3);
- not=EDcias (link 4)
- chamadas de principais not=EDcias (link 5)
A gera=E7=E3o da home, =E9 o ponto de partida de uma aplica=E7=E3o web,
normalmente temos um menu ou um bot=E3o de entrada, login ou qq coisa do
gen=EAro.
Vou me ater apenas a constru=E7=E3o do menu, o menu qdo constru=EDdo =
linkar=E1
para outras entidades / opera=E7=F5es, verificando tb pela defini=E7=E3o =
das
opera=E7=F5es, se h=E1 par=E2metros para serem passados para cada =
opera=E7=E3o.
Quando clicamos em um link, esse link pode se ir para o display ou
process da opera=E7=E3o, dependendo da configura=E7=E3o, 99% das vezes =
ir=E1 para
um display.=20
Quando clicamos no link o request chega at=E9 o framework:
1=BA esse abre a defini=E7=E3o da entidade, lendo assim suas =
defini=E7=F5es de
propriedades e opera=E7=F5es;
2=BA caso algum identificador de registro / objeto tenha sido passado,
instancia ou recupera o objeto em quest=E3o;
3=BA caso tenha sido passado valores de propriedades da entidade, o
framework seta os novos valores da propriedade (quest=F5es sobre
encapsulamento s=E3o facilmente resolvidas, antes que perguntem);
4=BA blake mescla as defini=E7=F5es de opera=E7=F5es e propriedades =
default, com o
que foi customizado pelo usu=E1rio, obviamente o que o usu=E1rio definir
deve prevalecer;
5=BA Nesse ponto o framework deve validar se ele continua o =
processamento,
ou seja, estamos em modo "autom=E1tico", ou se ele deve delegar isso a
algum m=E9todo da camada de neg=F3cio(Lembrando que camada de neg=F3cio =
est=E1
desacoplada do framework)
Supondo que estejamos em modo autom=E1tico + display
6=BA O framework chama o parser respons=E1vel por processar o tipo de
interface que a opera=E7=E3o exige
7=BA O parser instancia a classe document / page, e transforma a =
defini=E7=E3o
da opera=E7=E3o em chamadas de m=E9todos que setam as propriedades da
interface ;
8=BA O template engine faz o processamento para dar sa=EDda.
Supondo que estejamos em modo autom=E1tico + process
6=BA o framework chama o m=E9todo de persist=EAncia de dados, =
recuperando a
query de processamento da opera=E7=E3o em quest=E3o.
7=BA O m=E9todo verifica se h=E1 consist=EAncias a fazer:
a- caso existam e haja algum erro, gera o erro, e sa=ED;
8=BA Processa a query ou qq que seja a forma de persist=EAncia;
9=BA L=EA na defini=E7=E3o qual =E9 o m=E9todo para o qual deve ser =
redirecionado o
request, processa a informa=E7=E3o e redireciona para o display da =
opera=E7=E3o
em quest=E3o.
Supondo que n=E3o seja o modo autom=E1tico
6=BA Chama o m=E9todo da classe
Esse m=E9todo ser=E1 respons=E1vel por conversar com os parsers do =
framework e
dar algum tipo de sa=EDda, caso contr=E1rio deve ser gerado um =
exception.
Proponho uma coisa a vcs, tentem imaginar esse funcionamento que =
prop=FAs
acima em algumas funcionalidades, inclusive nas que mencionei no menu.
[]'s
Luiz
|
|
From: Carlos V. <ca...@bl...> - 2003-08-22 18:46:17
|
On Wed, 2003-08-20 at 19:48, lscheidegger - xdev wrote: > A geração da home, é o ponto de partida de uma aplicação web, > normalmente temos um menu ou um botão de entrada, login ou qq coisa do > genêro. Normal, nao precisamos nos preocupar com isso, pq toda essa parte o Inectis ja faz. O que a gente precisa eh bolar todo o esquema do desenvolvimento de aplicacoes (e nao sites) em cima disso que a gente ja tem :) > Quando clicamos em um link, esse link pode se ir para o display ou > process da operação, dependendo da configuração, 99% das vezes irá para > um display. E como vc faz display de uma operacao sem processar a dita cuja, criatura? :D Alias, sera que a gente podia usar uma nomenclatura decente? Link, display, process, operacao... esses termos nao estao fazendo o menor sentido pra mim (e acho que boa parte do pessoal compartilha dessa opiniao...). Pra mim, "link" nao eh nada mais do que um <a href...>, mas com certeza vc esta querendo dizer mto mais do que isso, nesse caso, e eu nao estou conseguindo entender direito. > Quando clicamos no link o request chega até o framework: > 1º esse abre a definição da entidade, lendo assim suas definições de > propriedades e operações; Nao creio que esse passo seja necessario... pq vc precisaria dele? > 2º caso algum identificador de registro / objeto tenha sido passado, > instancia ou recupera o objeto em questão; Ok > 3º caso tenha sido passado valores de propriedades da entidade, o > framework seta os novos valores da propriedade (questões sobre > encapsulamento são facilmente resolvidas, antes que perguntem); Entao, eu estou perguntando: como vc resolve questoes sobre encapsulamento? > 4º blake mescla as definições de operações e propriedades default, com o > que foi customizado pelo usuário, obviamente o que o usuário definir > deve prevalecer; Fica aqui de novo o papo sobre defaults. Eu nao aguento mais escrever referencias sobre isso :D A gente nao precisa desse ponto - o usuario ESCOLHEU os defaults, entao o Blake nao tem que mesclar nada - esta na definicao e pronto :) > 5º Nesse ponto o framework deve validar se ele continua o processamento, > ou seja, estamos em modo "automático", ou se ele deve delegar isso a > algum método da camada de negócio(Lembrando que camada de negócio está > desacoplada do framework) Modo automatico? Huh? Nao sei pq, parece que todos os dialogos do "Apertem os Cintos, o Piloto Sumiu!" vieram na minha cabeca :)~ > Supondo que estejamos em modo automático + display > 6º O framework chama o parser responsável por processar o tipo de > interface que a operação exige O que sao esses parsers? Como a operacao exige um parser? O que eh uma "interface"? (mais nomenclaturas bestas...) > 7º O parser instancia a classe document / page, e transforma a definição > da operação em chamadas de métodos que setam as propriedades da > interface ; Huh!? > 8º O template engine faz o processamento para dar saída. > > Supondo que estejamos em modo automático + process > 6º o framework chama o método de persistência de dados, recuperando a > query de processamento da operação em questão. E este metodo eh? E a query eh? Como eu sei qual a operacao em questao? > 7º O método verifica se há consistências a fazer: *SEMPRE* ha consistencias a fazer ;) > a- caso existam e haja algum erro, gera o erro, e sai; Gera qual erro? Sai pra onde? > 8º Processa a query ou qq que seja a forma de persistência; Como? > 9º Lê na definição qual é o método para o qual deve ser redirecionado o > request, processa a informação e redireciona para o display da operação > em questão. Huh?! > Supondo que não seja o modo automático > 6º Chama o método da classe > Esse método será responsável por conversar com os parsers do framework e > dar algum tipo de saída, caso contrário deve ser gerado um exception. Bullshit. Fazer a acao se comunicar com os parsers da um trabalho do cacete, coisa que nao eh necessaria... pq nao usar o modelo de scripted actions que eu propus... huuuuh... no 2o e-mail q eu mandei pra essa lista? :) > Proponho uma coisa a vcs, tentem imaginar esse funcionamento que propús > acima em algumas funcionalidades, inclusive nas que mencionei no menu. Sim, eu imaginei, e me deu coceira :P []'s -cv |
Thanks for helping keep SourceForge clean.
X