[Cascavel-pm] WxPerl e MVC

[Alceu R. de Freitas Jr.]

Champs, eu perdi seu post. Vou ter que me virar com a
resposta da resposta, mais abaixo...

> On 3/29/07, Luis Motta Campos
> <luismottacampos em yahoo.co.uk> wrote:
> >
> >    Eu quero ver. :-) Por favor?

A aplicação ainda não está 100%, quando faço o resize
do frame os objetos internos continuam do mesmo
tamanho... mas acho que dá para mostra alguma coisa
que apliquei de MVC.

Quer por email? Ou uso o Wiki do perl.org.br?

> >    Uh? Seu VIEW? Ele está fazendo papel de
> "Controller"? É função do
> > Controller tratar os eventos, e o fluxo de
> chamadas é sempre
> > Controller -> Model; Controller -> View, sendo que
> o Controller é o
> > lugar onde você tem de implementar seu negócio.

É, mas é aí que as coisas ficam interessantes, e por
isso minhas dúvidas. Lembra-se que WxPerl trabalha com
eventos? Bem, eu capturo um evento e nessa captura eu
aviso o Controller que algo mudou. Depois disso ele se
vira.

Uma das literaturas que eu li sobre MVC (acho que a
OOtips) fala que o Modelo manda mensagens para a View
também se alterar, mas através de uma interface, visto
que o modelo não deve ter conhecimento de como a View
é implementada. Por outro lado, a View CONHECE a
implementação do Model, portanto em algumas situações
eu simplesmente chamo um método diretamente do Model
para obter dados.

Ainda não cheguei em uma situação em que possa "medir"
os efeitos colaterais em fazer desse jeito. Uma das
minhas idéias é tentar usar o mesmo Model e Controller
e alterar a View para o programa funcionar em linha de
comando.

>    Acesso a dados deve estar todo implementado no
> Model, sendo
> > permitido ao Controller chamar métodos da
> interface pública para
> > obter dados do Model, mas nunca calcular dados
> extras (como uma
> > intersecção, por exemplo) para uma nova chamada.
> Se você precisa de
> > uma intersecção dos seus dados, o Model deve ser
> responsável pelo
> > cálculo. O Controller chama apenas GETters.

Ao que a aplicação está coerente com sua explicação.
Os modelos são simplesmente um DAO e uma classe que
representa um resultado, podendo converter em
diferentes formatos seu estado interno.

> >    Este é o funcionamento definido na
> implementação do Smalltalk
> > (qualquer sabor), datada da década de '70, mais ou
> menos... ;-)

Talvez um dia eu me aventure a fazer um "hello world"
em SmallTalk só para aprender mais sobre objetos.

> >    Views NUNCA GERAM EVENTOS. "Tenho um evento na
> View" é ter dois
> > problemas: a) você ainda não entendeu MVC; b) você
> implementou o
> > padrão de projeto errado. ;-) Eventos (mesmo que
> gerados pela
> > interface de usuário) devem ser encaminhados
> diretamente para o
> > Controller.

Sim papai, digo, Champs. Acho que explicação que dei
mais acima esclarece sobre o que tentei fazer.

De qualquer forma, muito obrigado pelas explicações
detalhadas. Vou usá-las como guia e rever partes do
código.

[]'s


Alceu Rodrigues de Freitas Junior
--------------------------------------
glasswalk3r em yahoo.com.br
http://www.imortais.cjb.net
-----------------------------------------------------------------------
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries -- The Tao Of Programming, 5.1

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/