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

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

>> O que fazemos normalmente =E9 criar uma defini=E7=E3o padr=E3o para =
cada=20
>> interface, opera=E7=E3o e propriedade, e mesclamos apenas as =
diferen=E7as=20
>> que a entidade/classe que est=E1 sendo processada tem.

>O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20
>consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 pra =

>fazer isso, mas eu n=E3o faco a menor id=E9ia de como... acho que eu =
vou
ter=20
>que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero
isso=20
>  - eu quero que todo o processo de criacao de uma aplicacao com o
Blake=20
>seja extremamente aberto, e customizavel.


A solu=E7=E3o para essa quest=E3o se refere menos a arquitetura ou api =
do
Blake, e mais com sua documenta=E7=E3o, principalmente seus quick =
starts,
HOWTO, e assim por diante.

Por mais que tentemos mapear todas as situa=E7=F5es que veremos, sempre
haver=E3o particularidades, e concordo que o sistema tem que ser aberto =
a
permitir tais particularidades, sem que necessariamente o usu=E1rio =
tenha
que desenvolver quebra galhos.

S=F3 que escrever toda a vez a defini=E7=E3o, caracter=EDstica a =
caracter=EDstica
da opera=E7=E3o ou propriedade, vc s=F3 est=E1 fazendo com que o =
usu=E1rio altere
o modelo de programa=E7=E3o que ele j=E1 conhe=E7e, sem dar um ganho =
t=E3o
expressivo de produtividade e qualidade. A ideia de mapear as
interfaces, =E9 encontrar o  "default", ter um padr=E3o para as =
situa=E7=F5es
mais cotidianas, e com um grau de abertura razo=E1vel que fa=E7a com que =
o
usu=E1rio n=E3o tenha que apelar.

O default n=E3o =E9 um engessamento, =E9 mais uma defini=E7=E3o padr=E3o =
que os
wizards seguir=E3o, caso o usu=E1rio n=E3o define as tais =
particularidades.

Inclusive o usu=E1rio deve poder a qualquer momento, tirar o blake do =
modo
autom=E1tico para determinada opera=E7=E3o, em qualquer uma das fases da
opera=E7=E3o.

N=F3s temos dois tipos de situa=E7=E3o:
- A autom=E1tica, na qual o framework l=EA as defini=E7=F5es, e essas se =
referem
apenas a elementos mapeados, e o blake assim far=E1 o processamento todo
automaticamente;
- A semi-autom=E1tica, blake continua lendo as defini=E7=F5es, s=F3 que
redirecionar=E1 o request para a camada de neg=F3cios, quando isso =
ocorrer,
inverte-se o comportamento, a camada de neg=F3cios acessar=E1 os objetos =
do
blake.

Dessa forma poderemos ter diversos graus de atua=E7=E3o do Blake, sem =
que
tenhamos que for=E7ar nada, ou que o usu=E1rio precise apelar.

O segredo do blake acima de tudo =E9 demonstrar um modelo, que os =
usu=E1rios
possam extender com facilidade, ou seja, mapear as interfaces e os
diversos tipos de content type das propriedades independentemente de que
tenhamos deixado implementado. Talvez uma boa solu=E7=E3o da quest=E3o
"Default", e deixar isso aberto para que o usu=E1rio defina o que deve =
ser
default para suas aplica=E7=F5es.