RES: [Blake-devel] Metodologia?

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

1. N=E3o, a metodologia n=E3o =E9 vamu fazendo pois o Blake ser=E1 =
apenas o 4
framework que implementa a metodologia, estamos discutindo o que ser=E1 =
do
Blake, que nada mais =E9 do que uma implementa=E7=E3o da metodologia. =
Acho
mais do que v=E1lido documentarmos em todo formato uml poss=EDvel, =
ali=E1s
acho interessante gerarmos os use cases qdo terminamos essa discuss=E3o =
de
features.

2. Sim,j=E1 vi. A diferen=E7a =E9 que eles geram efetivamente c=F3digo =
nativo da
linguagem que vc escolher, eu nunca consegui um demo ou nada parecido
deles, mas tenho bastante curiosidade de conhece-los. Tem um detalhe,
tudo deles =E9 propriet=E1rio.

[]'s

Luiz

-----Mensagem original-----
De: bla...@li...
[mailto:bla...@li...] Em nome de Guilherme
Silveira
Enviada em: quarta-feira, 20 de agosto de 2003 17:44
Para: bla...@li...
Assunto: [Blake-devel] Metodologia?


Perguntas:
1. Cade os diagramas e os use cases do projeto? Ou ainda nao tem? Ou a
metodologia vai ser "vamu fazendo"...? Sei que eh pesado, nao sei qual a
experiencia de cada um com uml e coisa e tal, mas pq nao comecar de um
jeito mais organizadinho? 2. Alguem ja viu o produto da apyon?
http://www.apyon.com.br/apm/index.htm
Existem outros produtos do genero... me falaram que o da apyon ja gera
tudo o que agente ta querendo...

Guilherme

----- Original Message -----
From: "Carlos Villela" <ca...@bl...>
To: <bla...@li...>
Sent: Wednesday, August 20, 2003 4:21 PM
Subject: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de
opera=E7=F5es


>
>
> lscheidegger - xdev wrote:
>
> > Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em =
conta que=20
> > teremos uma situa=E7=E3o padr=E3o definida para cada uma delas.
>
> Ok, mas como vc definiria a situacao padrao para a adicao de um=20
> objeto, por exemplo? IMHO, isto =E9 impossivel - voce nao consegue=20
> determinar, de forma generica, onde o objeto vai ser adicionado. Mesmo

> que vc tenha informacoes sobre o pai dele, existem diversos casos onde

> vc nao quer adicionar o objeto a um s=F3 pai (por exemplo, fazer um=20
> determinado usu=E1rio pertencer a v=E1rios grupos).
>
> Acho que se a gente quer fazer um framework que seja, de fato, util em

> todos os casos, nao podemos nos prender a criar "situacoes default",=20
> pq estas situacoes variam de projeto pra projeto, e de modelo pra=20
> modelo, principalmente, e mesmo sendo absurdamente customizaveis,=20
> ainda nao da pra encaixar 100% dos casos. A *unica* situacao default=20
> que a gente pode ter em mente eh:
>
> - Usuario navega pela aplicacao
> - Usuario seleciona uma operacao
> - Se a operacao precisar de dados para funcionar:
>    - Form apresentado pro usuario
>    - Usuario preenche dados, pressiona submit
>    - Dados sao validados
>      - Se a validacao ocorreu sem problemas:
>        - Executar a operacao
>        - Redirecionar o usuario a uma tela com resultados
>      - Se a validacao apontou inconsistencias:
>        - Re-exibir o formulario, com os dados e dicas de como=20
> corrigi-lo
> - Se a operacao puder ser executada sem input:
>    - Executar a operacao
>    - Redirecionar o usuario a uma tela com resultados
>
> Faltou alguma coisa aqui?
>
> > O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para =
cada=20
> > interface, opera=E7=E3o e propriedade, e mesclamos apenas as =
diferen=E7as=20
> > que a entidade/classe que est=E1 sendo processada tem.
>
> O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20
> consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 =
pra=20
> fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu =
vou=20
> ter que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao
quero isso
>   - eu quero que todo o processo de criacao de uma aplicacao com o=20
> Blake seja extremamente aberto, e customizavel.
>
> > Alguns pontos:
> >
> > - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de=20
> > neg=F3cio, a camada de neg=F3cios 100% das vezes s=E3o dados, por =
mais que

> > vc persista em objetos serializados.
>
> A camada de negocios =E9 feita de regras de neg=F3cio e dados, onde as =

> regras de neg=F3cio operam. Usando a API que eu descrevi no outro=20
> e-mail, n=F3s resolvemos o problema das duas. No seu modelo, a=20
> exist=EAncia das regras de neg=F3cios est=E1 sendo negada. Por isso vc
precisa de AOP - pq vc
>    esta deixando de levar em consideracao a outra metade do que =E9 =
uma=20
> camada de negocios ;)
>
> > O fato de vc guardar o id do objeto, em detrimento
> > do  rowid, ou do campo que =E9 primary key, faz com que vc guarde =
uma=20
> > refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre =

> > ter=E1 que guardar um indexador.
>
> Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem

> que seja o endereco de memoria onde eles estao. Mas voce precisa saber

> disso quando esta desenvolvendo um formulario de cadastro de clientes?

> Nao, voce nao deve ter que saber disso. Voce precisa de uma primary=20
> key? Nao - o unico caso onde eu vejo uma PK sendo util em uma=20
> aplicacao eh evitar a criacao de objetos com campos-chave duplicados,=20
> e, sinceramente, nao precisamos do peso conceitual e funcional de uma=20
> PK pra isso.
>
> > - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por =
mais=20
> > que seus livros falem isso, eles s=E3o complementares. =
Principalmente=20
> > pelo fato do modelo orientado a objeto ser extremamente trabalhoso=20
> > na camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. =
Enquanto=20
> > que no modelo que estamos propondo n=E3o.
>
> OO e R nao sao complementares, mas concordo se vc disser que OO eh um=20
> superset do modelo relacional. No modelo relacional, existem dados e=20
> relacionamento, mas nao existe polimorfismo, encapsulamento, mas=20
> existe identidade.
>
> E de onde vc tirou que "fato do modelo orientado a objeto ser=20
> extremamente trabalhoso na camada de neg=F3cios, onde seu=20
> reaproveitamento =E9 p=EDfio"? Poderia citar exemplos e fatos que=20
> comprovem essa afirmacao?
>
> > N=E3o adianta termos tudo orientado a objeto, estado da arte, se =
temos

> > uma dificuldade muito grande de reaproveitar o que j=E1 fizemos. =
-Quem

> > deve e ser=E1 completamente oop, =E9 o framework.
>
> Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte,

> entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework=20
> quanto o modelo devem ser OOP - se =E9 que a gente quer fazer algo=20
> estado-da-arte, como vc mesmo diz.
>
> >>>//indica que a primary key =E9 gerada automaticamente e n=E3o pode =
ser=20
> >>>alterada add.hiddenIdentifier(true);
> >
> >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh=20
> >>coisa do banco de dados - e eu sinceramente nem quero usar um, entao

> >>suma com essas nojeiras de modelo relacional da minha frente! :D
> >
> > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim=20
> > como quero tb usar o oracle. Cara sinto muito, n=E3o podemos=20
> > condicionar o uso do Blake com o uso do Prevayler.
>
> De onde vc tirou isso?
>
> Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao=20
> Prevayler. Eu so estou dizendo que fazer com que o usuario lide com=20
> IDs =E9 horrivel. Isso deve ser transparente pra ele - ele nao tem que =

> saber se o objeto que ele criou vai ser mapeado pra um banco de dados=20
> ou pra um punhado de objetos serializados (como eh o caso do=20
> Prevayler).
>
> ...ou por acaso vc nasceu com um ID estampado na testa? No mundo real,

> as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro=20
> de Pessoa Fisica, um documento, que, obviamente nao eh um ID.
>
>
> >>>//PROCESS
> >>>//define qual =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o =
processamento do

> >>>formul=E1rio add.setRedirectOperation("report");
> >
> >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes?=20
> >>:)
> >
> > Se tinha sido mapeado, eu n=E0o entendi onde e como.
>
> Quando eu criei novas Actions, e chamei addAction nas instancias de=20
> ClassDefinition (usuario e grupo).
>
> >>>//define a query de processamento
> >>>add.setQuery("add");
> >
> >>Que query? De onde vem esse "add"? Magica?
> >
> > N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel =
interpretar=E1 e=20
> > procurar=E1 uma query add, ou qq forma de persist=EAncia de dados=20
> > chamada add. Um dos conceitos do XDev, e que mantemos em arquivos=20
> > separados as classes/defini=E7=F5es e suas queries, dessa forma para =
um=20
> > User.java, tem um User.sql. Com rela=E7=E3o ao prevayler, teremos =
que=20
> > pensar uma alternativa.
>
> Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.=20
> Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta=20
> colocando os _metodos_ do objeto fora dele.
>
> >>>Supondo que essa seja a defini=E7=E3o padr=E3o de uma propriedade =
string:
> >>>string.setLenght(100)
> >>>string.isMandatory(false)
> >>>string.isVisible(true)
> >>>string.setCaption("")
> >>>string.isIdentifier(false)
> >
> >>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim=20
> >>a gente nao precisa ficar adicionando um >metodo novo na classe=20
> >>Property sempre que precisar de outro tipo de validacao.
> >
> >>Lembrando:
> >
> >>objeto.addConstraint("propriedade", new Constraint());
> >
> > Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o =
padr=E3o para

> > uma propriedade do tipo string. Ou seja se vc criar uma propriedade=20
> > string em sua entidade, e n=E3o informar mais nada, ela ter=E1=20
> > exatamente essa configura=E7=E3o.
>
> De novo, vamos ao debate sobre a "situacao default". Ter uma=20
> configura=E7=E3o assim nos seus objetos acontecendo por baixo dos =
panos =E9=20
> ruim, pq, afinal, est=E1 acontecendo debaixo dos panos.
>
> >>>Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico
> >>>(...)
> >>>
> >>>Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a=20
> >>>inclus=E3o.
> >>>
> >>>// Cria a definicao da classe
> >>>usuario =3D new ClassDefinition("Usuario");
> >>>
> >>>// Cria as propriedades que a classe vai ter=20
> >>>usuario.addProperty("id", Number.class);
> >
> >>AAAAAARGH! :D
> >
> > O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com =
base=20
> > em um template.
>
> Nao. O que esta sendo feito aqui =E9 adicionar uma propriedade que um=20
> Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome,
senha,
>    permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo=20
> um unico uso pra essa propriedade. Voce poderia me indicar um, que nao

> seja meramente a persistencia?
>
> []'s
> -cv
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Dice.com.
> Did you know that Dice has over 25,000 tech jobs available today? From

> careers in IT to Engineering to Tech Sales, Dice has tech jobs from=20
> the best hiring companies. =
http://www.dice.com/index.epl?rel_code=3D104
> _______________________________________________
> Blake-devel mailing list
> Bla...@li...=20
> https://lists.sourceforge.net/lists/listinfo/blake-devel
>




-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=3D104
_______________________________________________
Blake-devel mailing list
Bla...@li...
https://lists.sourceforge.net/lists/listinfo/blake-devel