blake-devel — Blake core developers

[Blake-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: RES: [Blake-devel] gm

[guilherme <gui...@su...>]

12 horas initerruptas na frente de um computador fazem agente embaralhar
tudo oq vai pro nosso sistema de I/O ... 

foi malz 



On Wed, 2003-10-01 at 21:23, Rafael Steil wrote:
> 	Mas nao por essa lista :)
> 
> Rafael
> 
> 
> -----Mensagem original-----
> De: bla...@li...
> [mailto:bla...@li...] Em nome de guilherme
> Enviada em: quarta-feira, 1 de outubro de 2003 21:25
> Para: bla...@li...
> Assunto: [Blake-devel] gm
> 
> 
> as coisas já estão lá - pasta supero.
> 
> vamos falando,
> 
> guilherme
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf _______________________________________________
> Blake-devel mailing list
> Bla...@li...
> https://lists.sourceforge.net/lists/listinfo/blake-devel
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Blake-devel mailing list
> Bla...@li...
> https://lists.sourceforge.net/lists/listinfo/blake-devel
> 

RES: [Blake-devel] gm

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

	Mas nao por essa lista :)

Rafael


-----Mensagem original-----
De: bla...@li...
[mailto:bla...@li...] Em nome de guilherme
Enviada em: quarta-feira, 1 de outubro de 2003 21:25
Para: bla...@li...
Assunto: [Blake-devel] gm


as coisas j=E1 est=E3o l=E1 - pasta supero.

vamos falando,

guilherme



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Blake-devel mailing list
Bla...@li...
https://lists.sourceforge.net/lists/listinfo/blake-devel

[Blake-devel] gm

[guilherme <gui...@su...>]

as coisas já estão lá - pasta supero.

vamos falando,

guilherme

[Blake-devel] teste

[lscheidegger - x. <lsc...@xd...>]

Ignorem por favor

Re: [Blake-devel] [Blake-devel] =?ISO-8859-1?Q?2=BA?= Qual =?ISO-8859-1?Q?ser=E1?= a =?ISO-8859-1?Q?abrang=EAncia?= do Blake

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

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

[Blake-devel] =?iso-8859-1?Q?=5BBlake-devel=5D_2=BA_Qual_ser=E1_a_abrang=EAncia_do_Blake?=

[lscheidegger - x. <lsc...@xd...>]

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

[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

RES: [Blake-devel] Metodologia?

[lscheidegger - x. <lsc...@xd...>]

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

[Blake-devel] =?iso-8859-1?Q?_=5BBlake-devel=5DComo_ser=E3o_definidas_as_opera=E7?= =?iso-8859-1?Q?=F5es_e_propriedades=3F?=

[lscheidegger - x. <lsc...@xd...>]

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

[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

[Blake-devel] Metodologia?

[Guilherme S. <gui...@gu...>]

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
>

[Blake-devel] =?iso-8859-1?Q?RES:_=5BBlake-devel=5D_Re:_=5BBlake-devel=5D_=5BBlake-deve?= =?iso-8859-1?Q?l=5D_-_Mapeamento_de_opera=E7=F5es?=

[lscheidegger - x. <lsc...@xd...>]

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

[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

[Blake-devel] =?iso-8859-1?Q?=5BBlake-devel=5D_-_Mapeamento_de_opera=E7=F5es?=

[lscheidegger - x. <lsc...@xd...>]

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

RES: [Blake-devel] Fontes do Inectis

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

	Bom,=20

-----Mensagem original-----
De: bla...@li...
[mailto:bla...@li...] Em nome de Guilherme
Silveira
Enviada em: ter=E7a-feira, 19 de agosto de 2003 09:55
Para: bla...@li...
Assunto: Re: [Blake-devel] Fontes do Inectis


> ... ao contrario do que o rafael disse, eu tenho a impressao que o
nested pode ser=20
> bastante requisitado dependendo do projeto.


Nos projetos que fiz ate hj, nao lembro de muitos casos onde um nested
fosse necessario. Mas, como tinha colocado no email anterior, por ser
relativamente simples de fazer, nao ha motivo de deixar de fora :)

[...]


> A definicao eh para montar os objetos? Mas os campos nao ficaram de
ser lidos atraves=20
> de reflection? Voce passa um bean e ele joga o campo la no formulario?

Isso eh um dos pontos que esta em aberto ainda. Estamos juntando as
ideias para soh entao definir como vai ser. Atualmente ha as
possiblidades de usar xml, doclet/reflection e coisas do genero. Mas
parece que estamos caminhando para o lado de=20


Rafael

Re: RES: RES: RES: [Blake-devel] Fontes do Inectis

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

On Tue, 2003-08-19 at 10:31, lscheidegger - xdev wrote:
> >Desvantagens:
> >- Tem alguma? Me avisem. ;)
> 
> Só uma, vc escreve pra diabo.

E voces nao ne?! :D

> //LINK
> //define a imagem que aparecerá no botão
> add.setImage("bt_inclusao.gif");
>
> //LINK + DISPLAY
> //Define o caption do link, bem como o título da página
> add.setTitle("Inclusão");
> 
> //DISPLAY
> //define que por default serão mostrados todas as propriedades no
> formulário
> add.getAllProperties(true);

Essa chamada ficou estranha. Era melhor:

add.showProperties(PropertyHelper.getAllProperties(usuario));

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

> //definição de subtítulo
> add.setSubtitle("");

Po, se vc nao vai setar o subtitulo, nao chame o metodo ;)

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

> //define a query de processamento
> add.setQuery("add");

Que query? De onde vem esse "add"? Magica?

> //define se há algum método de validação que deva ser chamado antes da
> inclusão
> add.setValidationMethod("validate");

"validate" o que? Como? O que acontece quando a validacao falha?

> 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());

> 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

> usuario.addProperty("nome", String.class);
> 
> //define que o campo id é chave primário, e que seu valor vem de uma
> seguence ou campo auto_increment
> usuario.properties.get("id").isIdentifier(true);
> usuario.properties.get("id").setType("sequencer");

AAAAAAAAAAAAAAAARGH!!! :D

> //define a legenda da propriedade nome
> usuario.properties.get("nome").setCaption("Nome do Usuário");

Hmm, nao gostei - a internacionalizacao vai pro saco se vc fizer isso ;)

> //addAction (String type,boolean automatic=true)
> usuario.addAction("add");

De novo, qual eh a magica que ta acontecendo aqui?

[]'s
-cv

[Blake-devel] (no subject)

[Daniel Q. O. <dan...@ho...>]

_________________________________________________________________
MSN Messenger: converse com os seus amigos online.  
http://messenger.msn.com.br

[Blake-devel] Blog interessante

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

http://freeroller.net/page/hugopinto/20030817

RES: [Blake-devel] Fontes do Inectis

[lscheidegger - x. <lsc...@xd...>]

[...]
>De qq jeito, minha opiniao fica: faca o report, funcionou, vai em
frente... (acho que mais ou menos o que o >carlos falou no primeiro
email)

Blz, eu tb concordo com isso, s=F3 quis esclarecer o tipo de coisa que
temos que resolver no futuro, a minha opini=E3o eu reitero, temos que
fazer as interfaces uma a uma, estressando bastante as possibilidades de
cada uma.

>ps: pq "blake"? (o q significa)
William Blake foi um poeta e pintor vision=E1rio que nasceu em 1753,1755
ou 1757 h=E1 controv=E9rsias. H=E1 uma aura de bruxo ou de louco em =
torno da
hist=F3ria dele, tanto sua pintura quanto poesia foram consideradas
inovadoras para a =E9poca que foram feitas.
Porque pensei nele? Porque eu queria homenagear algum artista, e ele foi
de um per=EDodo do in=EDcio da revolu=E7=E3o industrial, e em toda =
revolu=E7=E3o
como a industrial, ou a web, todos pensam que o mundo j=E1 est=E1 muito
evolu=EDdo, e que nada mais temos a desenvolver. N=E3o precisamos =
refletir
muito para ver o quanto a ind=FAstria mudou daquele tempo para c=E1, da
mesma forma a web mudar=E1, ela est=E1 em um est=E1gio muito =
embrion=E1rio, e a
minha proposta =E9 que sejamos algumas das pessoas que v=E3o levar a web
para o pr=F3ximo patamar evolucion=E1rio.

[]'s

Luiz

RES: RES: RES: [Blake-devel] Fontes do Inectis

[lscheidegger - x. <lsc...@xd...>]

>Desvantagens:
>- Tem alguma? Me avisem. ;)

S=F3 uma, vc escreve pra diabo.

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

//LINK
//define a imagem que aparecer=E1 no bot=E3o
add.setImage("bt_inclusao.gif");

//LINK + DISPLAY
//Define o caption do link, bem como o t=EDtulo da p=E1gina
add.setTitle("Inclus=E3o");

//DISPLAY
//define que por default ser=E3o mostrados todas as propriedades no
formul=E1rio
add.getAllProperties(true);
//indica que a primary key =E9 gerada automaticamente e n=E3o pode ser
alterada
add.hiddenIdentifier(true);
//defini=E7=E3o de subt=EDtulo
add.setSubtitle("");

//PROCESS
//define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o =
processamento do
formul=E1rio
add.setRedirectOperation("report");
//define a query de processamento
add.setQuery("add");
//define se h=E1 algum m=E9todo de valida=E7=E3o que deva ser chamado =
antes da
inclus=E3o
add.setValidationMethod("validate");

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)

Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico
number.setType(integer)
number.setCaption("")
number.minValue(null)
number.maxValue(null)
number.isIdentifier(false)
number.isMandatory(false)
number.isVisible(true)

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);
usuario.addProperty("nome", String.class);

//define que o campo id =E9 chave prim=E1rio, e que seu valor vem de uma
seguence ou campo auto_increment
usuario.properties.get("id").isIdentifier(true);
usuario.properties.get("id").setType("sequencer");

//define a legenda da propriedade nome
usuario.properties.get("nome").setCaption("Nome do Usu=E1rio");

//addAction (String type,boolean automatic=3Dtrue)
usuario.addAction("add");

[]'s

Luiz

Re: [Blake-devel] Fontes do Inectis

[Guilherme S. <gui...@gu...>]

Vamos la, vou colocar a opiniao nos pontos que achei que sao interessantes
para o comeco, o resto que parece ser muito especifico deixei de lado:

Uma vez que o list e o nested report nao passam de especializacoes, eles
deveriam ser tratados como report... (basico de oop). Se o report for
generico suficiente, list e nested serao gerados facilmente atraves deles.
Pessoalmente, eu consigo visualizar o report gerando um listreport facinho,
mas um nestedreport fica mais complicado e, ao contrario do que o rafael
disse, eu tenho a impressao que o nested pode ser bastante requisitado
dependendo do projeto.

De qq jeito, minha opiniao fica: faca o report, funcionou, vai em frente...
(acho que mais ou menos o que o carlos falou no primeiro email)

>> - Form (o clássico) título, subtítulo, campos, links

>Beleza, so falta definir cada um deles, especialmente o que eh um
>"campo" e um "link"

A definicao eh para montar os objetos? Mas os campos nao ficaram de ser
lidos atraves de reflection? Voce passa um bean e ele joga o campo la no
formulario?

A ferramenta de integracao: nao passa de uma interface a ser implementada
pelos cuspidores de html/wml/excel/o q for... e selecionadas atraves do
arquivo de definicao/request/...??

>> - Interfaces compostas como:
>>     - formulário em abas;
>Detalhe do template, nao?
O formulario em aba nao pode ser considerado um tipo de menu?

Nao seria interessante comecar com um ponto, tipo, FORM e ir em frente ate
ver ele funcionar do jeito desejado? Ai alguem vai pra frente com o REPORT
enquanto outra pessoa aperfeicoa e afina o FORM? e reticencias?

ps: pq "blake"? (o q significa)

Guilherme

RES: RES: RES: [Blake-devel] Fontes do Inectis

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

-----Mensagem original-----
De: bla...@li...
[mailto:bla...@li...] Em nome de Carlos
Villela
Enviada em: ter=E7a-feira, 19 de agosto de 2003 00:21
Para: bla...@li...
Assunto: Re: RES: RES: [Blake-devel] Fontes do Inectis

> Hmm, conflitou ja :D

> A minha visao sobre como o Inectis/Blake vai funcionar eh a seguinte:

> Suponha que vc esta fazendo um cadastro de usuarios e grupos. Suponha
que vc estivesse usando uma API=20
> imaginaria, que faz todo o trabalho sujo pra vc. Se coloque na pele
dum usuario do Inectis/Blake:

> [se preparem pra um loooongo bloco de codigo lindo]

Eu soh nao tenho certeza se entendi sobre qual parte do sistema eh essa
que vc mandou. Digo, eh a definicao final da interface, ou a definicao
de como ela vai ser? sao os campos e acoes que a tela tera, e com base
nisso o sistema "popula" os dados para entao serem processados pelo
carinha que monta a tela?

Rafael

Re: RES: RES: [Blake-devel] Fontes do Inectis

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

On Mon, 2003-08-18 at 22:49, Rafael Steil wrote:
> > Hmm...ainda falta mta coisa aih. Qual eh o objeto que representa a
> acao de um botao, quando clicado, por exemplo?
> 
> bom, atualmente nao existe um objeto que representa um botao, se bem
> entendi o que vc esta pensando... o que temos eh uma tag de link, onde
> dizemos o tipo dela ( continuar, boltar, inserir, submit, cancelar etc
> ), a qual vai para uma lista de links, e entao o sistema, com base no
> tipo, constroi as tags xml relacionadas, passando os parametros do link
> ( que estao na configuracao dele tmb ).... eh mais ou menos assim que
> funciona. A "acao do botao" seria a url/pagina/processamento disparado
> pelo click? se for isso, nao ha relacao alguma, pois o link/acao eh uma
> operacao no sistema ( report, insert, edit, o que quer que seja, como um
> link qualquer ).
> 

Hmm, conflitou ja :D

A minha visao sobre como o Inectis/Blake vai funcionar eh a seguinte:

Suponha que vc esta fazendo um cadastro de usuarios e grupos. Suponha
que vc estivesse usando uma API imaginaria, que faz todo o trabalho sujo
pra vc. Se coloque na pele dum usuario do Inectis/Blake:

[se preparem pra um loooongo bloco de codigo lindo]

// Cria as definicoes das classes
usuario = new ClassDefinition("Usuario");
grupo = new ClassDefinition("Grupo");

// Cria as propriedades que as classes vao ter
nome = new Property("nome", String.class);
senha = new Property("senha", String.class);
grupos = new Property("grupos", Set.class);
usuarios = new Property("usuarios", Set.class);

// Adiciona as propriedades as classes
usuario.addProperty(nome);
usuario.addProperty(senha);
usuario.addProperty(grupos);

grupo.addProperty(nome);
grupo.addProperty(usuarios);

// Adiciona os constraints que cada propriedade
// vai ter nesta classe especifica
usuario.addConstraint("nome", new MinimumSizeConstraint(6));
usuario.addConstraint("nome", new RequiredConstraint());
usuario.addConstraint("senha", new MinimumSizeConstraint(6));
usuario.addConstraint("senha", new RequiredConstraint());
usuario.addConstraint("grupos", new RequiredConstraint());
usuario.addConstraint("grupos", new MinimumCollectionSizeConstraint(1));
usuario.addConstraint("grupos", new TypeMatchConstraint(grupo));

grupo.addConstraint("nome", new MinimumSizeConstraint(6));
grupo.addConstraint("nome", new RequiredConstraint());
grupo.addConstraint("usuarios", new TypeMatchConstraint(usuario));

// Adiciona as acoes que cada objeto usuario pode receber
add = new Action("add");
del = new Action("delete");
edit = new Action("edit");
dup = new Action("duplicate");

// Define a regra de negocio para cada acao

add.addParameter(0, grupo);
add.addParameter(1, usuario);
add.setScript(
  function(system, params) {
    grupo = system.findGrupo(params.get("grupo"));
    grupo.addUsuario(params.get("usuario"));
  }
);

del.addParameter(0, grupo);
del.addParameter(1, usuario);
del.setScript(
  function(system, params) {
    grupo = system.findGrupo(params.get("grupo"));
    grupo.removeUsuario(params.get("usuario"));
  }
);

edit.addParameter(0, grupo);
edit.addParameter(1, usuario);
edit.addParameter(2, nome);
edit.addParameter(3, senha);
edit.setScript(
  function(system, params) {
    grupo = system.findGrupo(params.get("grupo"));
    usuario = grupo.findUsuario(params.get("usuario"));
    PropertyHelper.changeAllProperties(usuario, params);
  }
)

dup.addParameter(0, grupo);
dup.addParameter(1, usuario);
dup.addParameter(2, nome);
dup.setScript(
  function(system, params) {
    grupo = system.findGrupo(params.get("grupo"));
    usuario = grupo.findUsuario(params.get("usuario"));
    novo = new Usuario();
    PropertyHelper.changeAllProperties(novo,
		PropertyHelper.getAllProperties(usuario));
    novo.setNome(params.get("nome"));
    grupo.addUsuario(novo);
  }
)

usuario.addAction(add);
usuario.addAction(del);
usuario.addAction(edit);
usuario.addAction(dup);

// Adiciona as acoes que cada objeto grupo pode receber
add = new Action("add");
del = new Action("delete");
edit = new Action("edit");
dup = new Action("duplicate");

// Define a regra de negocio para cada acao

add.addParameter(0, grupo);
add.setScript(
  function(system, params) {
    system.addGrupo(params.get("grupo"));
  }
);

del.addParameter(0, grupo);
del.setScript(
  function(system, params) {
    system.removeGrupo(params.get("grupo"));
  }
);

edit.addParameter(0, grupo);
edit.addParameter(1, nome);
edit.addParameter(2, usuarios);
edit.setScript(
  function(system, params) {
    grupo = system.findGrupo(params.get("grupo"));
    PropertyHelper.changeAllProperties(grupo, params);
  }
)

dup.addParameter(0, grupo);
dup.addParameter(1, nome);
dup.setScript(
  function(system, params) {
    grupo = system.findGrupo(params.get("grupo"));
    novo = new Grupo();
    PropertyHelper.changeAllProperties(novo,
		PropertyHelper.getAllProperties(grupo));
    novo.setNome(params.get("nome"));
    system.addGrupo(grupo);
  }
)

usuario.addAction(add);
usuario.addAction(del);
usuario.addAction(edit);
usuario.addAction(dup);

// ------------------------------------------------------------
// ACABOU! ALELUIA! :D
// ------------------------------------------------------------

Agora vamo la'. Pra que eu tou falando disso tudo?

Vantagens e desvantagens deste modelo:

Vantagens:
- Totalmente independente da camada de visualizacao
- Super-facil de usar
- Properties e Actions altamente reutilizaveis
- Totalmente independente da interface que a gente vai usar pra definir
tudo isso (a gente nao quer que os caras facam esse JavaScript todo no
braco ne? :)

Desvantagens:
- Tem alguma? Me avisem. ;)

[]'s
-cv

RES: [Blake-devel] Fontes do Inectis

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

-----Mensagem original-----
De: bla...@li...
[mailto:bla...@li...] Em nome de lscheidegger
- xdevelopment
Enviada em: segunda-feira, 19 de agosto de 2002 00:04
Para: bla...@so...
Assunto: RES: [Blake-devel] Fontes do Inectis

[...]

> Ao inv=E9s disso acho que temos que deixar a interpreta=E7=E3o do que =
deve
ser uma campo em um formul=E1rio, para nosso > meio-campo, ou seja, a
ferramenta que utilizaremos para dar o parse do xml de defini=E7=E3o, no
caso o Velocity. A > minha proposta =E9 que nossa defini=E7=E3o saia
refletindo a orienta=E7=E3o a objeto, ou seja, com defini=E7=E3o de =
propriedades
> e m=E9todos, e o nosso parser com base no tipo de sa=EDda mais o tipo =
de
opera=E7=E3o/interface que foi solicitado no > request, gere um tipo de
sa=EDda adequado, portanto ter=EDamos um xml de defini=E7=E3o como esse:
<properties>
>   <number id=3D'id'>
>     <type>auto_increment</type>
>     <caption>Id do usu=E1rio</caption>
>   </string>
>   <string id=3D'nome'>
>     <length>100</length>
>     <mandatory>true</mandatory>
>     <caption>Nome do usu=E1rio</caption>
>   </string>

[..]

> Essa ferramenta de integra=E7=E3o que tem que entender que nosso =
defini=E7=E3o
acima em um tipo de sa=EDda html, em um > tipo de opera=E7=E3o de =
inclus=E3o
deve dar uma sa=EDda html de formul=E1rio, em outra sa=EDda como wml, =
deveria
gerar os > cards correspondentes. Ou seja, uma solu=E7=E3o abstrata.

Entao.. eis um ponto interessante. Nisso estamos considerando que o
resultado final estara em um formato XML, o qual devera ser processado
por alguma ferramenta para a construcao da interface. SE nesse caso
tratassemos tudo como objetos, ou seja, passar para o parser de
interface uma arvore com os objetos, poderiamos navegar por eles para
termos o que fosse necessario tambem, sendo ( com uma analise rapida,
claro ) bem mais simples interagir pelos dados.=20
O formato do objeto em si nao tenho mto definido, mas digamos que seria
como o formato do XML mesmo:

public class Seila {
    // Tipo: number, string, date etc
    private int type;

    private String caption;
    private boolean mandatory;

    // etc etc...

    // gets e sets
}

entao o sistema faz o processamento que precisar e vai construindo uma
arvore com esses objetos. Dai digamso que estamos usando o Velocity para
a cosntrucao da interface.. ficaria algo como

<!-- REPORT INTERFACE -->
<!-- Caption -->
<table>
#foreach ($caption in $tree.report.objetosDeCaptionList)
    <tr>
    #foreach ($name in $caption.names)
        <td><b>$name</b></td>
    #end
    </tr>
#end

<!-- Conteudo -->
#foreach ($line in $tree.report.objetosComOsDadosList)
    <tr>
    #foreach ($column in $line.columns)
        <td>$column.data</td>
    #end
    </tr>
#end

<!-- Links -->
#foreach ($link in $tree.report.linksList)
blablabla
#end

E assim por diante. Com isso conseguiriamos colocar qualquer tipo de
conteudo em qualquer canto da tela, de maneira simples.

Algo nesse estilo.

Rafael