You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(30) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <ben...@id...> - 2004-05-22 12:41:31
|
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 _______________________________________________________________________ |
From: guilherme <gui...@su...> - 2003-10-02 00:45:42
|
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 > |
From: Rafael S. <ra...@in...> - 2003-10-02 00:33:41
|
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 |
From: guilherme <gui...@su...> - 2003-10-02 00:25:03
|
as coisas já estão lá - pasta supero. vamos falando, guilherme |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-26 16:20:53
|
Ignorem por favor |
From: Carlos V. <ca...@bl...> - 2003-08-22 18:46:17
|
On Wed, 2003-08-20 at 19:48, lscheidegger - xdev wrote: > A geração da home, é o ponto de partida de uma aplicação web, > normalmente temos um menu ou um botão de entrada, login ou qq coisa do > genêro. Normal, nao precisamos nos preocupar com isso, pq toda essa parte o Inectis ja faz. O que a gente precisa eh bolar todo o esquema do desenvolvimento de aplicacoes (e nao sites) em cima disso que a gente ja tem :) > Quando clicamos em um link, esse link pode se ir para o display ou > process da operação, dependendo da configuração, 99% das vezes irá para > um display. E como vc faz display de uma operacao sem processar a dita cuja, criatura? :D Alias, sera que a gente podia usar uma nomenclatura decente? Link, display, process, operacao... esses termos nao estao fazendo o menor sentido pra mim (e acho que boa parte do pessoal compartilha dessa opiniao...). Pra mim, "link" nao eh nada mais do que um <a href...>, mas com certeza vc esta querendo dizer mto mais do que isso, nesse caso, e eu nao estou conseguindo entender direito. > Quando clicamos no link o request chega até o framework: > 1º esse abre a definição da entidade, lendo assim suas definições de > propriedades e operações; Nao creio que esse passo seja necessario... pq vc precisaria dele? > 2º caso algum identificador de registro / objeto tenha sido passado, > instancia ou recupera o objeto em questão; Ok > 3º caso tenha sido passado valores de propriedades da entidade, o > framework seta os novos valores da propriedade (questões sobre > encapsulamento são facilmente resolvidas, antes que perguntem); Entao, eu estou perguntando: como vc resolve questoes sobre encapsulamento? > 4º blake mescla as definições de operações e propriedades default, com o > que foi customizado pelo usuário, obviamente o que o usuário definir > deve prevalecer; Fica aqui de novo o papo sobre defaults. Eu nao aguento mais escrever referencias sobre isso :D A gente nao precisa desse ponto - o usuario ESCOLHEU os defaults, entao o Blake nao tem que mesclar nada - esta na definicao e pronto :) > 5º Nesse ponto o framework deve validar se ele continua o processamento, > ou seja, estamos em modo "automático", ou se ele deve delegar isso a > algum método da camada de negócio(Lembrando que camada de negócio está > desacoplada do framework) Modo automatico? Huh? Nao sei pq, parece que todos os dialogos do "Apertem os Cintos, o Piloto Sumiu!" vieram na minha cabeca :)~ > Supondo que estejamos em modo automático + display > 6º O framework chama o parser responsável por processar o tipo de > interface que a operação exige O que sao esses parsers? Como a operacao exige um parser? O que eh uma "interface"? (mais nomenclaturas bestas...) > 7º O parser instancia a classe document / page, e transforma a definição > da operação em chamadas de métodos que setam as propriedades da > interface ; Huh!? > 8º O template engine faz o processamento para dar saída. > > Supondo que estejamos em modo automático + process > 6º o framework chama o método de persistência de dados, recuperando a > query de processamento da operação em questão. E este metodo eh? E a query eh? Como eu sei qual a operacao em questao? > 7º O método verifica se há consistências a fazer: *SEMPRE* ha consistencias a fazer ;) > a- caso existam e haja algum erro, gera o erro, e sai; Gera qual erro? Sai pra onde? > 8º Processa a query ou qq que seja a forma de persistência; Como? > 9º Lê na definição qual é o método para o qual deve ser redirecionado o > request, processa a informação e redireciona para o display da operação > em questão. Huh?! > Supondo que não seja o modo automático > 6º Chama o método da classe > Esse método será responsável por conversar com os parsers do framework e > dar algum tipo de saída, caso contrário deve ser gerado um exception. Bullshit. Fazer a acao se comunicar com os parsers da um trabalho do cacete, coisa que nao eh necessaria... pq nao usar o modelo de scripted actions que eu propus... huuuuh... no 2o e-mail q eu mandei pra essa lista? :) > Proponho uma coisa a vcs, tentem imaginar esse funcionamento que propús > acima em algumas funcionalidades, inclusive nas que mencionei no menu. Sim, eu imaginei, e me deu coceira :P []'s -cv |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-22 13:27:32
|
>[..] A *unica* situacao default que a gente pode=20 >ter em mente eh: >- Usuario navega pela aplicacao >- Usuario seleciona uma operacao >- Se a operacao precisar de dados para funcionar: > - Form apresentado pro usuario > - Usuario preenche dados, pressiona submit > - Dados sao validados > - Se a validacao ocorreu sem problemas: > - Executar a operacao > - Redirecionar o usuario a uma tela com resultados > - Se a validacao apontou inconsistencias: > - Re-exibir o formulario, com os dados e dicas de como corrigi-lo >- Se a operacao puder ser executada sem input: > - Executar a operacao > - Redirecionar o usuario a uma tela com resultados >Faltou alguma coisa aqui? Temos muito mais opera=E7=F5es e interfaces na web do que o tradicional input/output. Form/report Mas como j=E1 chegamos a conclus=E3o podemos ir mapeando tudo aos = poucos. Eu resumiria o que vc est=E1 falando com: Link=3D>Display=3D>Processamento(opcional). Exemplo intranet: - home - menu (display) - lista de ramais (link 1 ); - classificados (link 2); - aniversariantes (link 3); - not=EDcias (link 4) - chamadas de principais not=EDcias (link 5) A gera=E7=E3o da home, =E9 o ponto de partida de uma aplica=E7=E3o web, normalmente temos um menu ou um bot=E3o de entrada, login ou qq coisa do gen=EAro. Vou me ater apenas a constru=E7=E3o do menu, o menu qdo constru=EDdo = linkar=E1 para outras entidades / opera=E7=F5es, verificando tb pela defini=E7=E3o = das opera=E7=F5es, se h=E1 par=E2metros para serem passados para cada = opera=E7=E3o. Quando clicamos em um link, esse link pode se ir para o display ou process da opera=E7=E3o, dependendo da configura=E7=E3o, 99% das vezes = ir=E1 para um display.=20 Quando clicamos no link o request chega at=E9 o framework: 1=BA esse abre a defini=E7=E3o da entidade, lendo assim suas = defini=E7=F5es de propriedades e opera=E7=F5es; 2=BA caso algum identificador de registro / objeto tenha sido passado, instancia ou recupera o objeto em quest=E3o; 3=BA caso tenha sido passado valores de propriedades da entidade, o framework seta os novos valores da propriedade (quest=F5es sobre encapsulamento s=E3o facilmente resolvidas, antes que perguntem); 4=BA blake mescla as defini=E7=F5es de opera=E7=F5es e propriedades = default, com o que foi customizado pelo usu=E1rio, obviamente o que o usu=E1rio definir deve prevalecer; 5=BA Nesse ponto o framework deve validar se ele continua o = processamento, ou seja, estamos em modo "autom=E1tico", ou se ele deve delegar isso a algum m=E9todo da camada de neg=F3cio(Lembrando que camada de neg=F3cio = est=E1 desacoplada do framework) Supondo que estejamos em modo autom=E1tico + display 6=BA O framework chama o parser respons=E1vel por processar o tipo de interface que a opera=E7=E3o exige 7=BA O parser instancia a classe document / page, e transforma a = defini=E7=E3o da opera=E7=E3o em chamadas de m=E9todos que setam as propriedades da interface ; 8=BA O template engine faz o processamento para dar sa=EDda. Supondo que estejamos em modo autom=E1tico + process 6=BA o framework chama o m=E9todo de persist=EAncia de dados, = recuperando a query de processamento da opera=E7=E3o em quest=E3o. 7=BA O m=E9todo verifica se h=E1 consist=EAncias a fazer: a- caso existam e haja algum erro, gera o erro, e sa=ED; 8=BA Processa a query ou qq que seja a forma de persist=EAncia; 9=BA L=EA na defini=E7=E3o qual =E9 o m=E9todo para o qual deve ser = redirecionado o request, processa a informa=E7=E3o e redireciona para o display da = opera=E7=E3o em quest=E3o. Supondo que n=E3o seja o modo autom=E1tico 6=BA Chama o m=E9todo da classe Esse m=E9todo ser=E1 respons=E1vel por conversar com os parsers do = framework e dar algum tipo de sa=EDda, caso contr=E1rio deve ser gerado um = exception. Proponho uma coisa a vcs, tentem imaginar esse funcionamento que = prop=FAs acima em algumas funcionalidades, inclusive nas que mencionei no menu. []'s Luiz |
From: Carlos V. <ca...@bl...> - 2003-08-22 05:37:16
|
> para GRANDE parte dos casos eh possivel criar situacoes padrao, que sao > simplesmemte inserir dados, deletar, fazer select etc etc.. situacoes > como "insira o registro do usuario, pegue entao o id gerado e adicione > este id na tabela de grupos, relacionando com x, y e z" sao excecoes a > regra, que nao acontecem todo o tempo. Opa, concordo - a gente pode resolver grande parte dos casos usando Actions padrao. O que eu tou chiando aqui é que, se a gente esconde isso do usuário, o blake vira só mais um monte de pó de pirlimpimpim inútil. Se for pra usar alguma coisa default, o usuário *deve, explicitamente*, escolher usar o default. É como assinar um contrato, dizendo "sim, eu sei o que os defaults fazem, e é exatamente isso que eu quero". Caso contrario, é só o cara esquecer de declarar uma Action pra alguma operacao, e a coisa toda fica parecendo passe de magica. > Por isso que eh preciso ter bem definida a parte de funcionamento para > quando tais excecoes forem necessarias. Por exemplo: no Oracle bastaria > simplesmente fazer uma procedure e disparar algum trigger ( ou fazer > tudo na procedure mesmo ).. Se estivesse usando MySQL, teria que fazer > queries diferentes, fazer codigo para isso ( execute a query, salve o id > em uma variavel e execute esta outra query ). Exatamente. Mas ficar pensando na base de dados nao vai ajudar aqui! Até EJBs CMP abstraem a base de dados pro usuário de uma certa forma, então pq a gente vai ter que se preocupar com ela aqui? ;) O que a gente tem que se focar sobre esse assunto é: como fazer o mapeamento das entidades pra um modelo de trabalho que, quando os objetos forem estupr...err, mapeados, pra uma base de dados, continuem transparentes pro usuario. O usuario do Blake nao tem que saber se ele foi deployado num Oracle, MySQL ou Prevayler. Ele só quer que a merda do formulario que ele tá criando apareca na tela, e que quando alguem digitar uma coisa nele e salvar, os dados fiquem seguros em algum lugar. > Veja, nao eh gambiarra, eh uma opcao que temos ( "processe isso com as > funcionaliaddes do framework, mas esta outra parque, que nada tem a ver > com o core, voce precisa com o metdo Y da classe X"). Funciona, e nao eh > gambiarra. Legal - nao acho que isso seja gambiarra, alias, eu achei ate bem elegante. Mas, vai aqui de novo a minha recomendacao de que todas as coisas "default" tem que ser explicitamente selecionadas, e nao só usadas assim pq o usuario esqueceu de configurar ;) > Porem, concordo *totalmente* contigo em muitos pontos, principalmente na > parte de que o cara vai sair fazendo gambiarra quando estiver "sem > prazo". Por isso, gostaria de saber qual eh a tua sugestao de solucao > para este casos especificos. Entao, o que vcs acharam de usar JavaScript ou outra linguagem de script pra que o usuario codifique estas excecoes? Eu achei uma boa sacada, pq essas linguagens, alem de nao precisar compilar, ainda tem a vantagem de ter profissionais baratos no mercado. Pra mim, no caso das actions, especificamente, os casos bizarros sao mto mais comuns do que os casos "default". Com os defaults, mesmo que nao tenha uma Action ja prontinha pra lidar com ele, é coisa de 2 ou 3 linhas resolver usando JS, e coisa de +/- 10 a 20 linhas pra resolver os casos mais esquisitos. Definitivamente, nao doi os dedos nem mata ninguem ;) > Ate agora foi mostrado como o Inectis > trabalha, como o XDev trabalha, varios conflitos de interesses, mas > nenhuma coisa definitiva ainda. Tenha calma... a gente ta juntando as ideias ainda, e elas sao bem diferentes. Ate chegar a hora do "então tá bom pra todo mundo", ainda vai um tempinho :) > Carlos, um dos pontos fortes do Blake eh que ele "adivinha" as coisas, > ja que tudo tem uma regra bem definida. Por exemplo, o lance do > mapeamento User.java -> User.sql . Considere a seguinte URL: > > host?entidade=User&operacao=report > > com base nisso, o que - atualmente - o blake/xdev faz: pega a entidade > "User", le a definicao dela e tudo mais. Entao vai la e *por default* > procura por um arquivo chamado "User.sql". Veja, o *default* eh isso, > mas se o arquivo se chamar *ABCDE.sql", basta dizer na especificacao que > o arquivo eh esse, sem complicacao. Ja o nome da query se chamar > "report" eh uma regra, mas nada impede de tambem especificar qual query > deve ser executada. Po, outra duvida: o que vai dentro desse User.sql? Se eu entendi bem ate agora, a gente nao tem a menor necessidade por isso, ja que a gente pode fazer todo o mapeamento sem fazer o coitado do usuario se enlamear todo com SQL, nao? > A parte de "definicao padrao para cada entidade" parece estar dando uma > certa confusao: o que estamos querendo dizer com "default" sao as > propriedades gerais. Por exemplo, considere as seguintes propriedades: > > -> User > nome > email > idade > cidade > telefone > cpf > > Digamos que, para todas as propriedades, elas sao visiveis por padrao. > Agora, se no report voce desejar mostrar apenas o nome, email e cpf, > voce vai na parte de definicao do report e diz que telefone, cidade e > idade nao vao ser visiveis ao usuario. Soh isso. Legal, disso eu gostei, mas, de novo, vai aqui minha enchecao de saco sobre coisas default ;) > (..) > O que eu gostaria de saber eh o seguinte: qual a tua sugestao para o > funcionamento disso? como funcionaria toda essa parte, como o sistema > atuaria, como eh feita a definicao? precisa refazer a definicao toda > hora que precisar de algo? da para mudar somente partes? > Veja, gostaria de algo concreto tambem, nao simplesmente "voce faz da > maneira que quiser, pois o sistema eh totalmetne generico".. O que > precisamos - eu, voce, luiz, todo mundo - eh definir de uma vez por > todas como vai ficar a parte de definicao de interface, de operacoes etc > etc... Como as nossas ideias se encaixam nas suas - e vice-versa. Glad you asked ;) Bom, as minhas sugestoes, ate agora, sao: - Fazer com que o usuario use apenas uma linguagem, apenas um conceito, apenas um paradigma. Que seja OOP (que eu prefiro), relacional, AOP (que eu tambem adoro, mas nao eh a salvacao da lavoura nesse caso), mas que seja um soh, pra nao ter aquela confusao de "uhhh, cadeira tem ID? eu vou ter que criar um objeto chamado CadeirasMesa?" e por ai vai :o) - Antes de pensar em usar QDox, XML, uma GUI ou o que quer que seja, vamos definir uma API. Assim, de cara, a gente ja consegue identificar o core do blake e o resto (as UIs). - Usar um modelo de constraints nas propriedades bem flexivel, para que seja, ao mesmo tempo, dar aos usuarios um conjunto com as constraints mais usadas (StringLength, Integer, Required, etc), e dar uma API mais facil ainda pra criar novas constraints e validacoes. Ia ser *do caralho* bolar um esquema que permitisse validacoes client-side tambem. Dá? :) > Como voce mesmo disse, temos que fazer algo que seja simples para o > usuario final usar, rapido de configurar e flexivel. Quais as tuas > sugestoes? :) Bom, as que eu consegui me lembrar ate agora (pega leve, eu tou sem dormir faz dias :D) eu coloquei ai em cima. Tenho certeza que mais sugestoes pipocaram nesses ultimos mails que eu mandei, mas sao mais sutis, entao eu acabei nao pegando quando os li de novo pra responder aqui. Se alguem notou alguma coisa legal que queria acrescentar, fique a vontade! :D BTW, gostei bastante da sua atitude aqui, Rafael - serviu pra mim como um "caralho, para de negar tudo que o Luiz fala e faz alguma coisa, porra!". Eu sei que nao foi essa a intencao, mas serviu seu proposito ;) []'s -cv |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 13:12:23
|
1. N=E3o, a metodologia n=E3o =E9 vamu fazendo pois o Blake ser=E1 = apenas o 4 framework que implementa a metodologia, estamos discutindo o que ser=E1 = do Blake, que nada mais =E9 do que uma implementa=E7=E3o da metodologia. = Acho mais do que v=E1lido documentarmos em todo formato uml poss=EDvel, = ali=E1s acho interessante gerarmos os use cases qdo terminamos essa discuss=E3o = de features. 2. Sim,j=E1 vi. A diferen=E7a =E9 que eles geram efetivamente c=F3digo = nativo da linguagem que vc escolher, eu nunca consegui um demo ou nada parecido deles, mas tenho bastante curiosidade de conhece-los. Tem um detalhe, tudo deles =E9 propriet=E1rio. []'s Luiz -----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de Guilherme Silveira Enviada em: quarta-feira, 20 de agosto de 2003 17:44 Para: bla...@li... Assunto: [Blake-devel] Metodologia? Perguntas: 1. Cade os diagramas e os use cases do projeto? Ou ainda nao tem? Ou a metodologia vai ser "vamu fazendo"...? Sei que eh pesado, nao sei qual a experiencia de cada um com uml e coisa e tal, mas pq nao comecar de um jeito mais organizadinho? 2. Alguem ja viu o produto da apyon? http://www.apyon.com.br/apm/index.htm Existem outros produtos do genero... me falaram que o da apyon ja gera tudo o que agente ta querendo... Guilherme ----- Original Message ----- From: "Carlos Villela" <ca...@bl...> To: <bla...@li...> Sent: Wednesday, August 20, 2003 4:21 PM Subject: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de opera=E7=F5es > > > lscheidegger - xdev wrote: > > > Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em = conta que=20 > > teremos uma situa=E7=E3o padr=E3o definida para cada uma delas. > > Ok, mas como vc definiria a situacao padrao para a adicao de um=20 > objeto, por exemplo? IMHO, isto =E9 impossivel - voce nao consegue=20 > determinar, de forma generica, onde o objeto vai ser adicionado. Mesmo > que vc tenha informacoes sobre o pai dele, existem diversos casos onde > vc nao quer adicionar o objeto a um s=F3 pai (por exemplo, fazer um=20 > determinado usu=E1rio pertencer a v=E1rios grupos). > > Acho que se a gente quer fazer um framework que seja, de fato, util em > todos os casos, nao podemos nos prender a criar "situacoes default",=20 > pq estas situacoes variam de projeto pra projeto, e de modelo pra=20 > modelo, principalmente, e mesmo sendo absurdamente customizaveis,=20 > ainda nao da pra encaixar 100% dos casos. A *unica* situacao default=20 > que a gente pode ter em mente eh: > > - Usuario navega pela aplicacao > - Usuario seleciona uma operacao > - Se a operacao precisar de dados para funcionar: > - Form apresentado pro usuario > - Usuario preenche dados, pressiona submit > - Dados sao validados > - Se a validacao ocorreu sem problemas: > - Executar a operacao > - Redirecionar o usuario a uma tela com resultados > - Se a validacao apontou inconsistencias: > - Re-exibir o formulario, com os dados e dicas de como=20 > corrigi-lo > - Se a operacao puder ser executada sem input: > - Executar a operacao > - Redirecionar o usuario a uma tela com resultados > > Faltou alguma coisa aqui? > > > O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para = cada=20 > > interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as=20 > > que a entidade/classe que est=E1 sendo processada tem. > > O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20 > consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 = pra=20 > fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu = vou=20 > ter que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso > - eu quero que todo o processo de criacao de uma aplicacao com o=20 > Blake seja extremamente aberto, e customizavel. > > > Alguns pontos: > > > > - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de=20 > > neg=F3cio, a camada de neg=F3cios 100% das vezes s=E3o dados, por = mais que > > vc persista em objetos serializados. > > A camada de negocios =E9 feita de regras de neg=F3cio e dados, onde as = > regras de neg=F3cio operam. Usando a API que eu descrevi no outro=20 > e-mail, n=F3s resolvemos o problema das duas. No seu modelo, a=20 > exist=EAncia das regras de neg=F3cios est=E1 sendo negada. Por isso vc precisa de AOP - pq vc > esta deixando de levar em consideracao a outra metade do que =E9 = uma=20 > camada de negocios ;) > > > O fato de vc guardar o id do objeto, em detrimento > > do rowid, ou do campo que =E9 primary key, faz com que vc guarde = uma=20 > > refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre = > > ter=E1 que guardar um indexador. > > Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem > que seja o endereco de memoria onde eles estao. Mas voce precisa saber > disso quando esta desenvolvendo um formulario de cadastro de clientes? > Nao, voce nao deve ter que saber disso. Voce precisa de uma primary=20 > key? Nao - o unico caso onde eu vejo uma PK sendo util em uma=20 > aplicacao eh evitar a criacao de objetos com campos-chave duplicados,=20 > e, sinceramente, nao precisamos do peso conceitual e funcional de uma=20 > PK pra isso. > > > - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por = mais=20 > > que seus livros falem isso, eles s=E3o complementares. = Principalmente=20 > > pelo fato do modelo orientado a objeto ser extremamente trabalhoso=20 > > na camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. = Enquanto=20 > > que no modelo que estamos propondo n=E3o. > > OO e R nao sao complementares, mas concordo se vc disser que OO eh um=20 > superset do modelo relacional. No modelo relacional, existem dados e=20 > relacionamento, mas nao existe polimorfismo, encapsulamento, mas=20 > existe identidade. > > E de onde vc tirou que "fato do modelo orientado a objeto ser=20 > extremamente trabalhoso na camada de neg=F3cios, onde seu=20 > reaproveitamento =E9 p=EDfio"? Poderia citar exemplos e fatos que=20 > comprovem essa afirmacao? > > > N=E3o adianta termos tudo orientado a objeto, estado da arte, se = temos > > uma dificuldade muito grande de reaproveitar o que j=E1 fizemos. = -Quem > > deve e ser=E1 completamente oop, =E9 o framework. > > Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte, > entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework=20 > quanto o modelo devem ser OOP - se =E9 que a gente quer fazer algo=20 > estado-da-arte, como vc mesmo diz. > > >>>//indica que a primary key =E9 gerada automaticamente e n=E3o pode = ser=20 > >>>alterada add.hiddenIdentifier(true); > > > >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh=20 > >>coisa do banco de dados - e eu sinceramente nem quero usar um, entao > >>suma com essas nojeiras de modelo relacional da minha frente! :D > > > > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim=20 > > como quero tb usar o oracle. Cara sinto muito, n=E3o podemos=20 > > condicionar o uso do Blake com o uso do Prevayler. > > De onde vc tirou isso? > > Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao=20 > Prevayler. Eu so estou dizendo que fazer com que o usuario lide com=20 > IDs =E9 horrivel. Isso deve ser transparente pra ele - ele nao tem que = > saber se o objeto que ele criou vai ser mapeado pra um banco de dados=20 > ou pra um punhado de objetos serializados (como eh o caso do=20 > Prevayler). > > ...ou por acaso vc nasceu com um ID estampado na testa? No mundo real, > as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro=20 > de Pessoa Fisica, um documento, que, obviamente nao eh um ID. > > > >>>//PROCESS > >>>//define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o = processamento do > >>>formul=E1rio add.setRedirectOperation("report"); > > > >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes?=20 > >>:) > > > > Se tinha sido mapeado, eu n=E0o entendi onde e como. > > Quando eu criei novas Actions, e chamei addAction nas instancias de=20 > ClassDefinition (usuario e grupo). > > >>>//define a query de processamento > >>>add.setQuery("add"); > > > >>Que query? De onde vem esse "add"? Magica? > > > > N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel = interpretar=E1 e=20 > > procurar=E1 uma query add, ou qq forma de persist=EAncia de dados=20 > > chamada add. Um dos conceitos do XDev, e que mantemos em arquivos=20 > > separados as classes/defini=E7=F5es e suas queries, dessa forma para = um=20 > > User.java, tem um User.sql. Com rela=E7=E3o ao prevayler, teremos = que=20 > > pensar uma alternativa. > > Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.=20 > Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta=20 > colocando os _metodos_ do objeto fora dele. > > >>>Supondo que essa seja a defini=E7=E3o padr=E3o de uma propriedade = string: > >>>string.setLenght(100) > >>>string.isMandatory(false) > >>>string.isVisible(true) > >>>string.setCaption("") > >>>string.isIdentifier(false) > > > >>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim=20 > >>a gente nao precisa ficar adicionando um >metodo novo na classe=20 > >>Property sempre que precisar de outro tipo de validacao. > > > >>Lembrando: > > > >>objeto.addConstraint("propriedade", new Constraint()); > > > > Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o = padr=E3o para > > uma propriedade do tipo string. Ou seja se vc criar uma propriedade=20 > > string em sua entidade, e n=E3o informar mais nada, ela ter=E1=20 > > exatamente essa configura=E7=E3o. > > De novo, vamos ao debate sobre a "situacao default". Ter uma=20 > configura=E7=E3o assim nos seus objetos acontecendo por baixo dos = panos =E9=20 > ruim, pq, afinal, est=E1 acontecendo debaixo dos panos. > > >>>Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico > >>>(...) > >>> > >>>Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a=20 > >>>inclus=E3o. > >>> > >>>// Cria a definicao da classe > >>>usuario =3D new ClassDefinition("Usuario"); > >>> > >>>// Cria as propriedades que a classe vai ter=20 > >>>usuario.addProperty("id", Number.class); > > > >>AAAAAARGH! :D > > > > O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com = base=20 > > em um template. > > Nao. O que esta sendo feito aqui =E9 adicionar uma propriedade que um=20 > Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome, senha, > permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo=20 > um unico uso pra essa propriedade. Voce poderia me indicar um, que nao > seja meramente a persistencia? > > []'s > -cv > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from=20 > the best hiring companies. = http://www.dice.com/index.epl?rel_code=3D104 > _______________________________________________ > Blake-devel mailing list > Bla...@li...=20 > https://lists.sourceforge.net/lists/listinfo/blake-devel > ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=3D104 _______________________________________________ Blake-devel mailing list Bla...@li... https://lists.sourceforge.net/lists/listinfo/blake-devel |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 12:23:16
|
>> O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para = cada=20 >> interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as=20 >> que a entidade/classe que est=E1 sendo processada tem. >O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20 >consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 pra = >fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu = vou ter=20 >que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso=20 > - eu quero que todo o processo de criacao de uma aplicacao com o Blake=20 >seja extremamente aberto, e customizavel. A solu=E7=E3o para essa quest=E3o se refere menos a arquitetura ou api = do Blake, e mais com sua documenta=E7=E3o, principalmente seus quick = starts, HOWTO, e assim por diante. Por mais que tentemos mapear todas as situa=E7=F5es que veremos, sempre haver=E3o particularidades, e concordo que o sistema tem que ser aberto = a permitir tais particularidades, sem que necessariamente o usu=E1rio = tenha que desenvolver quebra galhos. S=F3 que escrever toda a vez a defini=E7=E3o, caracter=EDstica a = caracter=EDstica da opera=E7=E3o ou propriedade, vc s=F3 est=E1 fazendo com que o = usu=E1rio altere o modelo de programa=E7=E3o que ele j=E1 conhe=E7e, sem dar um ganho = t=E3o expressivo de produtividade e qualidade. A ideia de mapear as interfaces, =E9 encontrar o "default", ter um padr=E3o para as = situa=E7=F5es mais cotidianas, e com um grau de abertura razo=E1vel que fa=E7a com que = o usu=E1rio n=E3o tenha que apelar. O default n=E3o =E9 um engessamento, =E9 mais uma defini=E7=E3o padr=E3o = que os wizards seguir=E3o, caso o usu=E1rio n=E3o define as tais = particularidades. Inclusive o usu=E1rio deve poder a qualquer momento, tirar o blake do = modo autom=E1tico para determinada opera=E7=E3o, em qualquer uma das fases da opera=E7=E3o. N=F3s temos dois tipos de situa=E7=E3o: - A autom=E1tica, na qual o framework l=EA as defini=E7=F5es, e essas se = referem apenas a elementos mapeados, e o blake assim far=E1 o processamento todo automaticamente; - A semi-autom=E1tica, blake continua lendo as defini=E7=F5es, s=F3 que redirecionar=E1 o request para a camada de neg=F3cios, quando isso = ocorrer, inverte-se o comportamento, a camada de neg=F3cios acessar=E1 os objetos = do blake. Dessa forma poderemos ter diversos graus de atua=E7=E3o do Blake, sem = que tenhamos que for=E7ar nada, ou que o usu=E1rio precise apelar. O segredo do blake acima de tudo =E9 demonstrar um modelo, que os = usu=E1rios possam extender com facilidade, ou seja, mapear as interfaces e os diversos tipos de content type das propriedades independentemente de que tenhamos deixado implementado. Talvez uma boa solu=E7=E3o da quest=E3o "Default", e deixar isso aberto para que o usu=E1rio defina o que deve = ser default para suas aplica=E7=F5es. |
From: Rafael S. <ra...@in...> - 2003-08-21 08:03:17
|
Olha,=20 -----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de Carlos Villela Enviada em: quarta-feira, 20 de agosto de 2003 16:22 Para: bla...@li... Assunto: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de opera=E7=F5es > Acho que se a gente quer fazer um framework que seja, de fato, util em > todos os casos, nao podemos nos prender a criar "situacoes default", pq=20 > estas situacoes variam de projeto pra projeto, e de modelo pra modelo, > principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da > pra encaixar 100% dos casos. A *unica* situacao default que a gente pode=20 > ter em mente eh: para GRANDE parte dos casos eh possivel criar situacoes padrao, que sao simplesmemte inserir dados, deletar, fazer select etc etc.. situacoes como "insira o registro do usuario, pegue entao o id gerado e adicione este id na tabela de grupos, relacionando com x, y e z" sao excecoes a regra, que nao acontecem todo o tempo.=20 Por isso que eh preciso ter bem definida a parte de funcionamento para quando tais excecoes forem necessarias. Por exemplo: no Oracle bastaria simplesmente fazer uma procedure e disparar algum trigger ( ou fazer tudo na procedure mesmo ).. Se estivesse usando MySQL, teria que fazer queries diferentes, fazer codigo para isso ( execute a query, salve o id em uma variavel e execute esta outra query ). O sistema precisa suportar esse tipo de coisa, como voce mesmo citou. A implementacao atual do xdev nos da limitacoes sim, em muitos casos precisamos redirecionar o processamento para codigo da entidade ( quando eh algo muito em especifico ). Veja, nao eh gambiarra, eh uma opcao que temos ( "processe isso com as funcionaliaddes do framework, mas esta outra parque, que nada tem a ver com o core, voce precisa com o metdo Y da classe X"). Funciona, e nao eh gambiarra.=20 Porem, concordo *totalmente* contigo em muitos pontos, principalmente na parte de que o cara vai sair fazendo gambiarra quando estiver "sem prazo". Por isso, gostaria de saber qual eh a tua sugestao de solucao para este casos especificos. Ate agora foi mostrado como o Inectis trabalha, como o XDev trabalha, varios conflitos de interesses, mas nenhuma coisa definitiva ainda.=20 Carlos, um dos pontos fortes do Blake eh que ele "adivinha" as coisas, ja que tudo tem uma regra bem definida. Por exemplo, o lance do mapeamento User.java -> User.sql . Considere a seguinte URL: host?entidade=3DUser&operacao=3Dreport com base nisso, o que - atualmente - o blake/xdev faz: pega a entidade "User", le a definicao dela e tudo mais. Entao vai la e *por default* procura por um arquivo chamado "User.sql". Veja, o *default* eh isso, mas se o arquivo se chamar *ABCDE.sql", basta dizer na especificacao que o arquivo eh esse, sem complicacao. Ja o nome da query se chamar "report" eh uma regra, mas nada impede de tambem especificar qual query deve ser executada.=20 A parte de "definicao padrao para cada entidade" parece estar dando uma certa confusao: o que estamos querendo dizer com "default" sao as propriedades gerais. Por exemplo, considere as seguintes propriedades: -> User nome email idade cidade telefone cpf Digamos que, para todas as propriedades, elas sao visiveis por padrao. Agora, se no report voce desejar mostrar apenas o nome, email e cpf, voce vai na parte de definicao do report e diz que telefone, cidade e idade nao vao ser visiveis ao usuario. Soh isso.=20 Agora, se vc precisar atualizar os dados, o que voce precisa? primeiro, o cara clica em "editar", e entao vai ser dado um "SELECT * FROM User WHERE id =3D ?" .. Isso logicamente nao eh coisa do blake, qualquer sistema que use banco de dados faz isso. Na hora de atualizar os dados, eh dado um "UPDATE xxxx", certo? Isso o blake faz sozinho, vc nao precisa configurar nada alem da entidade.=20 Agora, digamos que estivessemos usando MySQL e que fosse necessario dar update em umas 3 tabelas quando editar o usuario. Como o mysql nao tem procedures, nem trigger nem nada, como fica o caso? sentamos e choramos? nao, nos dizemod que, para a operacao de update, um metodo especial deve ser chamado ( sim, precisamos codar este metodo a parte do framework ).=20 O que eu gostaria de saber eh o seguinte: qual a tua sugestao para o funcionamento disso? como funcionaria toda essa parte, como o sistema atuaria, como eh feita a definicao? precisa refazer a definicao toda hora que precisar de algo? da para mudar somente partes?=20 Veja, gostaria de algo concreto tambem, nao simplesmente "voce faz da maneira que quiser, pois o sistema eh totalmetne generico".. O que precisamos - eu, voce, luiz, todo mundo - eh definir de uma vez por todas como vai ficar a parte de definicao de interface, de operacoes etc etc... Como as nossas ideias se encaixam nas suas - e vice-versa.=20 Como voce mesmo disse, temos que fazer algo que seja simples para o usuario final usar, rapido de configurar e flexivel. Quais as tuas sugestoes? :) Rafael |
From: Guilherme S. <gui...@gu...> - 2003-08-21 02:46:48
|
Perguntas: 1. Cade os diagramas e os use cases do projeto? Ou ainda nao tem? Ou a metodologia vai ser "vamu fazendo"...? Sei que eh pesado, nao sei qual a experiencia de cada um com uml e coisa e tal, mas pq nao comecar de um jeito mais organizadinho? 2. Alguem ja viu o produto da apyon? http://www.apyon.com.br/apm/index.htm Existem outros produtos do genero... me falaram que o da apyon ja gera tudo o que agente ta querendo... Guilherme ----- Original Message ----- From: "Carlos Villela" <ca...@bl...> To: <bla...@li...> Sent: Wednesday, August 20, 2003 4:21 PM Subject: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de operações > > > lscheidegger - xdev wrote: > > > Ao mapear as interfaces e operações, nós temos que ter em conta que > > teremos uma situação padrão definida para cada uma delas. > > Ok, mas como vc definiria a situacao padrao para a adicao de um objeto, > por exemplo? IMHO, isto é impossivel - voce nao consegue determinar, de > forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha > informacoes sobre o pai dele, existem diversos casos onde vc nao quer > adicionar o objeto a um só pai (por exemplo, fazer um determinado > usuário pertencer a vários grupos). > > Acho que se a gente quer fazer um framework que seja, de fato, util em > todos os casos, nao podemos nos prender a criar "situacoes default", pq > estas situacoes variam de projeto pra projeto, e de modelo pra modelo, > principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da > pra encaixar 100% dos casos. A *unica* situacao default que a gente pode > ter em mente eh: > > - Usuario navega pela aplicacao > - Usuario seleciona uma operacao > - Se a operacao precisar de dados para funcionar: > - Form apresentado pro usuario > - Usuario preenche dados, pressiona submit > - Dados sao validados > - Se a validacao ocorreu sem problemas: > - Executar a operacao > - Redirecionar o usuario a uma tela com resultados > - Se a validacao apontou inconsistencias: > - Re-exibir o formulario, com os dados e dicas de como corrigi-lo > - Se a operacao puder ser executada sem input: > - Executar a operacao > - Redirecionar o usuario a uma tela com resultados > > Faltou alguma coisa aqui? > > > O que fazemos normalmente é criar uma definição padrão para cada > > interface, operação e propriedade, e mesclamos apenas as diferenças que > > a entidade/classe que está sendo processada tem. > > O problema de fazer isso eh que vc engessa demais a coisa - eu já > consigo ver usuarios do Blake se perguntando "putz, eu sei que dá pra > fazer isso, mas eu não faco a menor idéia de como... acho que eu vou ter > que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso > - eu quero que todo o processo de criacao de uma aplicacao com o Blake > seja extremamente aberto, e customizavel. > > > Alguns pontos: > > > > - O que o blake possibilitará é criar rapidamente a camada de negócio, a > > camada de negócios 100% das vezes são dados, por mais que vc persista em > > objetos serializados. > > A camada de negocios é feita de regras de negócio e dados, onde as > regras de negócio operam. Usando a API que eu descrevi no outro e-mail, > nós resolvemos o problema das duas. No seu modelo, a existência das > regras de negócios está sendo negada. Por isso vc precisa de AOP - pq vc > esta deixando de levar em consideracao a outra metade do que é uma > camada de negocios ;) > > > O fato de vc guardar o id do objeto, em detrimento > > do rowid, ou do campo que é primary key, faz com que vc guarde uma > > referência ao objeto / registro da mesma forma. Em suma, vc sempre terá > > que guardar um indexador. > > Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem > que seja o endereco de memoria onde eles estao. Mas voce precisa saber > disso quando esta desenvolvendo um formulario de cadastro de clientes? > Nao, voce nao deve ter que saber disso. Voce precisa de uma primary key? > Nao - o unico caso onde eu vejo uma PK sendo util em uma aplicacao eh > evitar a criacao de objetos com campos-chave duplicados, e, > sinceramente, nao precisamos do peso conceitual e funcional de uma PK > pra isso. > > > - O modelo relacional não é oposto ao orientado a objeto por mais que > > seus livros falem isso, eles são complementares. Principalmente pelo > > fato do modelo orientado a objeto ser extremamente trabalhoso na camada > > de negócios, onde seu reaproveitamento é pífio. Enquanto que no modelo > > que estamos propondo não. > > OO e R nao sao complementares, mas concordo se vc disser que OO eh um > superset do modelo relacional. No modelo relacional, existem dados e > relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe > identidade. > > E de onde vc tirou que "fato do modelo orientado a objeto ser > extremamente trabalhoso na camada de negócios, onde seu reaproveitamento > é pífio"? Poderia citar exemplos e fatos que comprovem essa afirmacao? > > > Não adianta termos tudo orientado a objeto, estado da arte, se temos uma > > dificuldade muito grande de reaproveitar o que já fizemos. > > -Quem deve e será completamente oop, é o framework. > > Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte, > entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework > quanto o modelo devem ser OOP - se é que a gente quer fazer algo > estado-da-arte, como vc mesmo diz. > > >>>//indica que a primary key é gerada automaticamente e não pode ser > >>>alterada > >>>add.hiddenIdentifier(true); > > > >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh > >>coisa do banco de dados - e eu sinceramente nem quero usar um, entao > >>suma com essas nojeiras de modelo relacional da minha frente! :D > > > > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim como > > quero tb usar o oracle. Cara sinto muito, não podemos condicionar o uso > > do Blake com o uso do Prevayler. > > De onde vc tirou isso? > > Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao > Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs > é horrivel. Isso deve ser transparente pra ele - ele nao tem que saber > se o objeto que ele criou vai ser mapeado pra um banco de dados ou pra > um punhado de objetos serializados (como eh o caso do Prevayler). > > ...ou por acaso vc nasceu com um ID estampado na testa? No mundo real, > as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro de > Pessoa Fisica, um documento, que, obviamente nao eh um ID. > > > >>>//PROCESS > >>>//define qual é a operação que será chamada após o processamento do > >>>formulário add.setRedirectOperation("report"); > > > >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :) > > > > Se tinha sido mapeado, eu nào entendi onde e como. > > Quando eu criei novas Actions, e chamei addAction nas instancias de > ClassDefinition (usuario e grupo). > > >>>//define a query de processamento > >>>add.setQuery("add"); > > > >>Que query? De onde vem esse "add"? Magica? > > > > Não definição padrão, que o wizard responsável interpretará e procurará > > uma query add, ou qq forma de persistência de dados chamada add. Um dos > > conceitos do XDev, e que mantemos em arquivos separados as > > classes/definições e suas queries, dessa forma para um User.java, tem um > > User.sql. Com relação ao prevayler, teremos que pensar uma alternativa. > > Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo. > Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta > colocando os _metodos_ do objeto fora dele. > > >>>Supondo que essa seja a definição padrão de uma propriedade string: > >>>string.setLenght(100) > >>>string.isMandatory(false) > >>>string.isVisible(true) > >>>string.setCaption("") > >>>string.isIdentifier(false) > > > >>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim a > >>gente nao precisa ficar adicionando um >metodo novo na classe Property > >>sempre que precisar de outro tipo de validacao. > > > >>Lembrando: > > > >>objeto.addConstraint("propriedade", new Constraint()); > > > > Esse não é um modelo de constraints, e sim uma definição padrão para uma > > propriedade do tipo string. Ou seja se vc criar uma propriedade string > > em sua entidade, e não informar mais nada, ela terá exatamente essa > > configuração. > > De novo, vamos ao debate sobre a "situacao default". Ter uma > configuração assim nos seus objetos acontecendo por baixo dos panos é > ruim, pq, afinal, está acontecendo debaixo dos panos. > > >>>Essa é a definição padrão de um campo numérico > >>>(...) > >>> > >>>Vamos criar uma entidade Usuário, vou exemplificar apenas a inclusão. > >>> > >>>// Cria a definicao da classe > >>>usuario = new ClassDefinition("Usuario"); > >>> > >>>// Cria as propriedades que a classe vai ter > >>>usuario.addProperty("id", Number.class); > > > >>AAAAAARGH! :D > > > > O que está sendo feito aqui é adicionando uma propriedade, com base em > > um template. > > Nao. O que esta sendo feito aqui é adicionar uma propriedade que um > Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome, senha, > permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo um > unico uso pra essa propriedade. Voce poderia me indicar um, que nao seja > meramente a persistencia? > > []'s > -cv > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > _______________________________________________ > Blake-devel mailing list > Bla...@li... > https://lists.sourceforge.net/lists/listinfo/blake-devel > |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 00:33:07
|
Acho que est=E1 na hora de separarmos as discuss=F5es. De outra forma = cada e-mail ser=E1 um livro =E9 uma queda de bra=E7os em v=E1rias frentes. 1=BA Como ser=E3o definidas as opera=E7=F5es e propriedades; 2=BA Qual ser=E1 a abrang=EAncia do Blake; 3=BA Como faremos persist=EAncia de dados, como relacionaremos registros = x objetos; 4=BA Como e quanto das interfaces ser=E3o mapeadas; Responderei cada quest=E3o em um e-mail At=E9 -----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de Carlos Villela Enviada em: quarta-feira, 20 de agosto de 2003 16:22 Para: bla...@li... Assunto: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de opera=E7=F5es lscheidegger - xdev wrote: > Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em conta = que=20 > teremos uma situa=E7=E3o padr=E3o definida para cada uma delas. Ok, mas como vc definiria a situacao padrao para a adicao de um objeto,=20 por exemplo? IMHO, isto =E9 impossivel - voce nao consegue determinar, = de=20 forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha=20 informacoes sobre o pai dele, existem diversos casos onde vc nao quer=20 adicionar o objeto a um s=F3 pai (por exemplo, fazer um determinado=20 usu=E1rio pertencer a v=E1rios grupos). Acho que se a gente quer fazer um framework que seja, de fato, util em=20 todos os casos, nao podemos nos prender a criar "situacoes default", pq=20 estas situacoes variam de projeto pra projeto, e de modelo pra modelo,=20 principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da=20 pra encaixar 100% dos casos. A *unica* situacao default que a gente pode ter em mente eh: - Usuario navega pela aplicacao - Usuario seleciona uma operacao - Se a operacao precisar de dados para funcionar: - Form apresentado pro usuario - Usuario preenche dados, pressiona submit - Dados sao validados - Se a validacao ocorreu sem problemas: - Executar a operacao - Redirecionar o usuario a uma tela com resultados - Se a validacao apontou inconsistencias: - Re-exibir o formulario, com os dados e dicas de como corrigi-lo - Se a operacao puder ser executada sem input: - Executar a operacao - Redirecionar o usuario a uma tela com resultados Faltou alguma coisa aqui? > O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para = cada=20 > interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as=20 > que a entidade/classe que est=E1 sendo processada tem. O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20 consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 pra=20 fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu vou = ter que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso - eu quero que todo o processo de criacao de uma aplicacao com o Blake seja extremamente aberto, e customizavel. > Alguns pontos: >=20 > - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de = neg=F3cio, > a camada de neg=F3cios 100% das vezes s=E3o dados, por mais que vc=20 > persista em objetos serializados. A camada de negocios =E9 feita de regras de neg=F3cio e dados, onde as=20 regras de neg=F3cio operam. Usando a API que eu descrevi no outro = e-mail,=20 n=F3s resolvemos o problema das duas. No seu modelo, a exist=EAncia das=20 regras de neg=F3cios est=E1 sendo negada. Por isso vc precisa de AOP - = pq vc esta deixando de levar em consideracao a outra metade do que =E9 uma=20 camada de negocios ;) > O fato de vc guardar o id do objeto, em detrimento > do rowid, ou do campo que =E9 primary key, faz com que vc guarde uma=20 > refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre=20 > ter=E1 que guardar um indexador. Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem=20 que seja o endereco de memoria onde eles estao. Mas voce precisa saber=20 disso quando esta desenvolvendo um formulario de cadastro de clientes?=20 Nao, voce nao deve ter que saber disso. Voce precisa de uma primary key? Nao - o unico caso onde eu vejo uma PK sendo util em uma aplicacao eh=20 evitar a criacao de objetos com campos-chave duplicados, e,=20 sinceramente, nao precisamos do peso conceitual e funcional de uma PK=20 pra isso. > - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por mais = que=20 > seus livros falem isso, eles s=E3o complementares. Principalmente pelo = > fato do modelo orientado a objeto ser extremamente trabalhoso na=20 > camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. Enquanto = que no > modelo que estamos propondo n=E3o. OO e R nao sao complementares, mas concordo se vc disser que OO eh um=20 superset do modelo relacional. No modelo relacional, existem dados e=20 relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe=20 identidade. E de onde vc tirou que "fato do modelo orientado a objeto ser=20 extremamente trabalhoso na camada de neg=F3cios, onde seu = reaproveitamento =E9 p=EDfio"? Poderia citar exemplos e fatos que comprovem essa = afirmacao? > N=E3o adianta termos tudo orientado a objeto, estado da arte, se temos = > uma dificuldade muito grande de reaproveitar o que j=E1 fizemos. -Quem = > deve e ser=E1 completamente oop, =E9 o framework. Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte,=20 entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework=20 quanto o modelo devem ser OOP - se =E9 que a gente quer fazer algo=20 estado-da-arte, como vc mesmo diz. >>>//indica que a primary key =E9 gerada automaticamente e n=E3o pode = ser >>>alterada >>>add.hiddenIdentifier(true); >=20 >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh >>coisa do banco de dados - e eu sinceramente nem quero usar um, entao >>suma com essas nojeiras de modelo relacional da minha frente! :D >=20 > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim=20 > como quero tb usar o oracle. Cara sinto muito, n=E3o podemos = condicionar > o uso do Blake com o uso do Prevayler. De onde vc tirou isso? Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao=20 Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs=20 =E9 horrivel. Isso deve ser transparente pra ele - ele nao tem que saber = se o objeto que ele criou vai ser mapeado pra um banco de dados ou pra=20 um punhado de objetos serializados (como eh o caso do Prevayler). ...ou por acaso vc nasceu com um ID estampado na testa? No mundo real,=20 as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro de Pessoa Fisica, um documento, que, obviamente nao eh um ID. >>>//PROCESS >>>//define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o = processamento do >>>formul=E1rio add.setRedirectOperation("report"); >=20 >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :) >=20 > Se tinha sido mapeado, eu n=E0o entendi onde e como. Quando eu criei novas Actions, e chamei addAction nas instancias de=20 ClassDefinition (usuario e grupo). >>>//define a query de processamento >>>add.setQuery("add"); >=20 >>Que query? De onde vem esse "add"? Magica? >=20 > N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel = interpretar=E1 e=20 > procurar=E1 uma query add, ou qq forma de persist=EAncia de dados = chamada=20 > add. Um dos conceitos do XDev, e que mantemos em arquivos separados as > classes/defini=E7=F5es e suas queries, dessa forma para um User.java, = tem=20 > um User.sql. Com rela=E7=E3o ao prevayler, teremos que pensar uma=20 > alternativa. Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.=20 Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta=20 colocando os _metodos_ do objeto fora dele. >>>Supondo que essa seja a defini=E7=E3o padr=E3o de uma propriedade = string: >>>string.setLenght(100) >>>string.isMandatory(false) >>>string.isVisible(true) >>>string.setCaption("") >>>string.isIdentifier(false) >=20 >>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim a >>gente nao precisa ficar adicionando um >metodo novo na classe Property >>sempre que precisar de outro tipo de validacao. >=20 >>Lembrando: >=20 >>objeto.addConstraint("propriedade", new Constraint()); >=20 > Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o = padr=E3o para=20 > uma propriedade do tipo string. Ou seja se vc criar uma propriedade=20 > string em sua entidade, e n=E3o informar mais nada, ela ter=E1 = exatamente=20 > essa configura=E7=E3o. De novo, vamos ao debate sobre a "situacao default". Ter uma=20 configura=E7=E3o assim nos seus objetos acontecendo por baixo dos panos = =E9=20 ruim, pq, afinal, est=E1 acontecendo debaixo dos panos. >>>Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico >>>(...) >>> >>>Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a = inclus=E3o. >>> >>>// Cria a definicao da classe >>>usuario =3D new ClassDefinition("Usuario"); >>> >>>// Cria as propriedades que a classe vai ter >>>usuario.addProperty("id", Number.class); >=20 >>AAAAAARGH! :D >=20 > O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com = base em > um template. Nao. O que esta sendo feito aqui =E9 adicionar uma propriedade que um=20 Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome, senha, permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo um unico uso pra essa propriedade. Voce poderia me indicar um, que nao seja meramente a persistencia? []'s -cv ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=3D104 _______________________________________________ Blake-devel mailing list Bla...@li... https://lists.sourceforge.net/lists/listinfo/blake-devel |
From: Carlos V. <ca...@bl...> - 2003-08-20 19:37:11
|
lscheidegger - xdev wrote: > Ao mapear as interfaces e operações, nós temos que ter em conta que > teremos uma situação padrão definida para cada uma delas. Ok, mas como vc definiria a situacao padrao para a adicao de um objeto, por exemplo? IMHO, isto é impossivel - voce nao consegue determinar, de forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha informacoes sobre o pai dele, existem diversos casos onde vc nao quer adicionar o objeto a um só pai (por exemplo, fazer um determinado usuário pertencer a vários grupos). Acho que se a gente quer fazer um framework que seja, de fato, util em todos os casos, nao podemos nos prender a criar "situacoes default", pq estas situacoes variam de projeto pra projeto, e de modelo pra modelo, principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da pra encaixar 100% dos casos. A *unica* situacao default que a gente pode ter em mente eh: - Usuario navega pela aplicacao - Usuario seleciona uma operacao - Se a operacao precisar de dados para funcionar: - Form apresentado pro usuario - Usuario preenche dados, pressiona submit - Dados sao validados - Se a validacao ocorreu sem problemas: - Executar a operacao - Redirecionar o usuario a uma tela com resultados - Se a validacao apontou inconsistencias: - Re-exibir o formulario, com os dados e dicas de como corrigi-lo - Se a operacao puder ser executada sem input: - Executar a operacao - Redirecionar o usuario a uma tela com resultados Faltou alguma coisa aqui? > O que fazemos normalmente é criar uma definição padrão para cada > interface, operação e propriedade, e mesclamos apenas as diferenças que > a entidade/classe que está sendo processada tem. O problema de fazer isso eh que vc engessa demais a coisa - eu já consigo ver usuarios do Blake se perguntando "putz, eu sei que dá pra fazer isso, mas eu não faco a menor idéia de como... acho que eu vou ter que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso - eu quero que todo o processo de criacao de uma aplicacao com o Blake seja extremamente aberto, e customizavel. > Alguns pontos: > > - O que o blake possibilitará é criar rapidamente a camada de negócio, a > camada de negócios 100% das vezes são dados, por mais que vc persista em > objetos serializados. A camada de negocios é feita de regras de negócio e dados, onde as regras de negócio operam. Usando a API que eu descrevi no outro e-mail, nós resolvemos o problema das duas. No seu modelo, a existência das regras de negócios está sendo negada. Por isso vc precisa de AOP - pq vc esta deixando de levar em consideracao a outra metade do que é uma camada de negocios ;) > O fato de vc guardar o id do objeto, em detrimento > do rowid, ou do campo que é primary key, faz com que vc guarde uma > referência ao objeto / registro da mesma forma. Em suma, vc sempre terá > que guardar um indexador. Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem que seja o endereco de memoria onde eles estao. Mas voce precisa saber disso quando esta desenvolvendo um formulario de cadastro de clientes? Nao, voce nao deve ter que saber disso. Voce precisa de uma primary key? Nao - o unico caso onde eu vejo uma PK sendo util em uma aplicacao eh evitar a criacao de objetos com campos-chave duplicados, e, sinceramente, nao precisamos do peso conceitual e funcional de uma PK pra isso. > - O modelo relacional não é oposto ao orientado a objeto por mais que > seus livros falem isso, eles são complementares. Principalmente pelo > fato do modelo orientado a objeto ser extremamente trabalhoso na camada > de negócios, onde seu reaproveitamento é pífio. Enquanto que no modelo > que estamos propondo não. OO e R nao sao complementares, mas concordo se vc disser que OO eh um superset do modelo relacional. No modelo relacional, existem dados e relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe identidade. E de onde vc tirou que "fato do modelo orientado a objeto ser extremamente trabalhoso na camada de negócios, onde seu reaproveitamento é pífio"? Poderia citar exemplos e fatos que comprovem essa afirmacao? > Não adianta termos tudo orientado a objeto, estado da arte, se temos uma > dificuldade muito grande de reaproveitar o que já fizemos. > -Quem deve e será completamente oop, é o framework. Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte, entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework quanto o modelo devem ser OOP - se é que a gente quer fazer algo estado-da-arte, como vc mesmo diz. >>>//indica que a primary key é gerada automaticamente e não pode ser >>>alterada >>>add.hiddenIdentifier(true); > >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh >>coisa do banco de dados - e eu sinceramente nem quero usar um, entao >>suma com essas nojeiras de modelo relacional da minha frente! :D > > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim como > quero tb usar o oracle. Cara sinto muito, não podemos condicionar o uso > do Blake com o uso do Prevayler. De onde vc tirou isso? Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs é horrivel. Isso deve ser transparente pra ele - ele nao tem que saber se o objeto que ele criou vai ser mapeado pra um banco de dados ou pra um punhado de objetos serializados (como eh o caso do Prevayler). ...ou por acaso vc nasceu com um ID estampado na testa? No mundo real, as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro de Pessoa Fisica, um documento, que, obviamente nao eh um ID. >>>//PROCESS >>>//define qual é a operação que será chamada após o processamento do >>>formulário add.setRedirectOperation("report"); > >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :) > > Se tinha sido mapeado, eu nào entendi onde e como. Quando eu criei novas Actions, e chamei addAction nas instancias de ClassDefinition (usuario e grupo). >>>//define a query de processamento >>>add.setQuery("add"); > >>Que query? De onde vem esse "add"? Magica? > > Não definição padrão, que o wizard responsável interpretará e procurará > uma query add, ou qq forma de persistência de dados chamada add. Um dos > conceitos do XDev, e que mantemos em arquivos separados as > classes/definições e suas queries, dessa forma para um User.java, tem um > User.sql. Com relação ao prevayler, teremos que pensar uma alternativa. Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo. Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta colocando os _metodos_ do objeto fora dele. >>>Supondo que essa seja a definição padrão de uma propriedade string: >>>string.setLenght(100) >>>string.isMandatory(false) >>>string.isVisible(true) >>>string.setCaption("") >>>string.isIdentifier(false) > >>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim a >>gente nao precisa ficar adicionando um >metodo novo na classe Property >>sempre que precisar de outro tipo de validacao. > >>Lembrando: > >>objeto.addConstraint("propriedade", new Constraint()); > > Esse não é um modelo de constraints, e sim uma definição padrão para uma > propriedade do tipo string. Ou seja se vc criar uma propriedade string > em sua entidade, e não informar mais nada, ela terá exatamente essa > configuração. De novo, vamos ao debate sobre a "situacao default". Ter uma configuração assim nos seus objetos acontecendo por baixo dos panos é ruim, pq, afinal, está acontecendo debaixo dos panos. >>>Essa é a definição padrão de um campo numérico >>>(...) >>> >>>Vamos criar uma entidade Usuário, vou exemplificar apenas a inclusão. >>> >>>// Cria a definicao da classe >>>usuario = new ClassDefinition("Usuario"); >>> >>>// Cria as propriedades que a classe vai ter >>>usuario.addProperty("id", Number.class); > >>AAAAAARGH! :D > > O que está sendo feito aqui é adicionando uma propriedade, com base em > um template. Nao. O que esta sendo feito aqui é adicionar uma propriedade que um Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome, senha, permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo um unico uso pra essa propriedade. Voce poderia me indicar um, que nao seja meramente a persistencia? []'s -cv |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-20 14:13:37
|
S=F3 mudei o subject, porque o subject j=E1 mudou faz tempo :) Bom carlos, acho que vc n=E3o entendeu muito o que estava propondo, o principal do outro e-mail era: Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em conta = que teremos uma situa=E7=E3o padr=E3o definida para cada uma delas. O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para cada interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as que a entidade/classe que est=E1 sendo processada tem. Supondo que a defini=E7=E3o padr=E3o da opera=E7=E3o add seja (seguindo = seu padr=E3o): [...] O que estava sendo proposto era menos um formato de c=F3digo, e mais um conceito. Esse conceito =E9: - Vamos mapear tipos de propriedades e tipos de opera=E7=E3o (link+display+process), como templates. - Depois disso vinculamos essas propriedades e opera=E7=F5es mapeadas as classes da camada de neg=F3cio. Alguns pontos: - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de = neg=F3cio, a camada de neg=F3cios 100% das vezes s=E3o dados, por mais que vc = persista em objetos serializados. O fato de vc guardar o id do objeto, em detrimento do rowid, ou do campo que =E9 primary key, faz com que vc guarde uma refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre = ter=E1 que guardar um indexador. - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por mais = que seus livros falem isso, eles s=E3o complementares. Principalmente pelo fato do modelo orientado a objeto ser extremamente trabalhoso na camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. Enquanto que no = modelo que estamos propondo n=E3o.=20 N=E3o adianta termos tudo orientado a objeto, estado da arte, se temos = uma dificuldade muito grande de reaproveitar o que j=E1 fizemos.=20 -Quem deve e ser=E1 completamente oop, =E9 o framework. O resto comentarei no pr=F3prio c=F3digo >>Desvantagens: >>- Tem alguma? Me avisem. ;) >> >> S=F3 uma, vc escreve pra diabo. >E voces nao ne?! :D Na verdade n=E3o, porque o c=F3digo seria s=F3 a v=EDnculo da entidade = com suas propriedades e m=E9todos. /// ESSE PEDA=C7O DE C=D3DIGO SE REFERE A UMA DEFINI=C7=C3O PADR=C3O DE = UMA OPERA=C7=C3O N=C3O VINCULADA A NENHUMA ENTIDADE >> //LINK >> //define a imagem que aparecer=E1 no bot=E3o=20 >> add.setImage("bt_inclusao.gif"); > >> //LINK + DISPLAY >> //Define o caption do link, bem como o t=EDtulo da p=E1gina=20 >> add.setTitle("Inclus=E3o"); > >> //DISPLAY >> //define que por default ser=E3o mostrados todas as propriedades no=20 >> formul=E1rio add.getAllProperties(true); >> //indica que a primary key =E9 gerada automaticamente e n=E3o pode = ser=20 >>alterada >>add.hiddenIdentifier(true); >Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh=20 >coisa do banco de dados - e eu >>>sinceramente nem quero usar um, entao >suma com essas nojeiras de modelo relacional da minha frente! :D Entenda isso como um indexador. Eu tb quero usar o prevayler, assim como quero tb usar o oracle. Cara sinto muito, n=E3o podemos condicionar o = uso do Blake com o uso do prevayler.=20 >> //defini=E7=E3o de subt=EDtulo >> add.setSubtitle(""); >Po, se vc nao vai setar o subtitulo, nao chame o metodo ;) S=F3 pus isso ai, para mostrar que existe a possibilidade de setar um subt=EDtulo >> //PROCESS >> //define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o = processamento do=20 >> formul=E1rio add.setRedirectOperation("report"); >Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :) Se tinha sido mapeado, eu n=E0o entendi onde e como. >> //define a query de processamento >> add.setQuery("add"); >Que query? De onde vem esse "add"? Magica? N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel interpretar=E1 = e procurar=E1 uma query add, ou qq forma de persist=EAncia de dados chamada add. Um = dos conceitos do XDev, e que mantemos em arquivos separados as classes/defini=E7=F5es e suas queries, dessa forma para um User.java, = tem um User.sql. Com rela=E7=E3o ao prevayler, teremos que pensar uma = alternativa. >> //define se h=E1 algum m=E9todo de valida=E7=E3o que deva ser chamado = antes=20 >> da inclus=E3o >>add.setValidationMethod("validate"); >"validate" o que? Como? O que acontece quando a validacao falha? Supondo que vc precise de um valida=E7=E3o server-side bem espec=EDfica, = ap=F3s um processamento, como propriedades unique em databases que n=E3o tem = esse tipo de constraint, vc pode por reflection chamar o m=E9todo que vc indicou nessa fun=E7=E3o, esse m=E9todo far=E1 as consist=EAncias = necess=E1rio, gerando um erro, ou retornando true. >> Supondo que essa seja a defini=E7=E3o padr=E3o de uma propriedade = string: >> string.setLenght(100) >> string.isMandatory(false) >> string.isVisible(true) >> string.setCaption("") >> string.isIdentifier(false) >Hmm... eu gostei mais do modelo de constraints que eu bolei - assim a=20 >gente nao precisa ficar adicionando um >metodo novo na classe Property=20 >sempre que precisar de outro tipo de validacao. >Lembrando: >objeto.addConstraint("propriedade", new Constraint()); Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o = padr=E3o para uma propriedade do tipo string. Ou seja se vc criar uma propriedade string em sua entidade, e n=E3o informar mais nada, ela ter=E1 exatamente essa configura=E7=E3o. >> Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico >> (...) >> >> Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a = inclus=E3o. >> >> // Cria a definicao da classe >> usuario =3D new ClassDefinition("Usuario"); >> >> // Cria as propriedades que a classe vai ter=20 >> usuario.addProperty("id", Number.class); >AAAAAARGH! :D O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com base = em um template. >> usuario.addProperty("nome", String.class); >> >> //define que o campo id =E9 chave prim=E1rio, e que seu valor vem de = uma=20 >> seguence ou campo auto_increment=20 >> usuario.properties.get("id").isIdentifier(true); >> usuario.properties.get("id").setType("sequencer"); >AAAAAAAAAAAAAAAARGH!!! :D Idem. >> //define a legenda da propriedade nome=20 >> usuario.properties.get("nome").setCaption("Nome do Usu=E1rio"); >Hmm, nao gostei - a internacionalizacao vai pro saco se vc fizer isso=20 >;) Isso pode facilmente ser resolvido, n=E3o? >> //addAction (String type,boolean automatic=3Dtrue)=20 >> usuario.addAction("add"); >De novo, qual eh a magica que ta acontecendo aqui? Vc est=E1 vinculando um template de opera=E7=E3o a uma entidade. []'s Luiz |
From: Rafael S. <ra...@in...> - 2003-08-20 03:59:01
|
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 |
From: Carlos V. <ca...@bl...> - 2003-08-20 03:55:21
|
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 |
From: Daniel Q. O. <dan...@ho...> - 2003-08-19 21:16:45
|
_________________________________________________________________ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br |
From: Carlos V. <ca...@bl...> - 2003-08-19 21:13:34
|
http://freeroller.net/page/hugopinto/20030817 |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-19 13:44:55
|
[...] >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 |
From: lscheidegger - x. <lsc...@xd...> - 2003-08-19 13:31:43
|
>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 |
From: Guilherme S. <gui...@gu...> - 2003-08-19 12:54:35
|
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 |
From: Rafael S. <ra...@in...> - 2003-08-19 03:46:25
|
-----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 |
From: Carlos V. <ca...@bl...> - 2003-08-19 03:20:57
|
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 |
From: Rafael S. <ra...@in...> - 2003-08-19 03:19:57
|
-----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 |