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