Material do Artigo - Webwork 2

Parabéns pelo seu Artigo sobre o WebWork 2, ficou muito bom, e realmente me parece que esse Webwork é uma mão na roda para desenvolivmento de softwares com interface Web.

Eu li o artigo, puxei os arquivos e funcionou legal, mas tenho algumas dúvidas que gostaria que você me esclarecesse se possível. Vamos lá

:arrow: Você disse que o servlet Initializer seria o primeiro a ser inicializado quando o servidor entrasse no ar, certo? Onde você configurou isso? onde nos arquivos de configuração isso é descrito?

:arrow: Dentro do web.xml você mapeou um Filter <filter-class>com.opensymphony.webwork.lifecycle.RequestLifecycleFilter</filter-class>, qual a sua finalidade? que vantagem eu ganharia com isso?

:arrow: No mesmo arquivo, você mapeou um Listener <listener-class>com.opensymphony.webwork.lifecycle.SessionLifecycleListener</listener-class> qual a vantagem de ter um Listener?

:arrow: Pelo que eu entendi, caso você queria deixar uma classe na sessão, no artigo seria o UserSession, eu preciso criar um arquivo chamado component.xml e definir sua classe e também é obrigado a implementar uma interface, pois esse é o padrão do IoC tipo 1, certo?

:arrow: Depois do usuário ter efetuado o Login correto, você jogou para a sessão as informações do Usuário. Para um “espertinho” não entrar diretamente em um arquivo .jsp sem passar pelo login, ele pode colocar a URL diretamente desse arquivo. Para mim bloquear isso, eu terei que fazer um teste de session em todos os arquivos .JSP? Ou o webwork se encarrega disso de alguma maneira? Se eu terei que implementar isso, como ficaria no caso o arquivo interno.jsp para o usuário não acessá-lo diretamente?

Por enquanto é só :!: (tantas dúvidas e eu ainda digo só :twisted: )

Obrigado [/code]

Ueba … vamos por parte, como o Jack.

Ele é criado antes de alguem acessar a aplicacação simplesmente pela instrução <load-on-startup>1</load-on-startup>
Não é importante ser o primeiro e sim ser instanciado antes de acessarem pra podermos fazer algumas configurações e tal sem pesar pro usuário.

O RequestLifecycleFilter é responsável por gerenciar os componentes da sua aplicação para cada requisição. (eu acho)

Mais uma vez este é um recurso do Framework.

Os componentes tem seu ciclo de vida ligado aos escopos de sessão e aplicação (e requisição) , por isso é necessário o listener.
O Webwork usa um ComponentManager armazenado na sessão do usuário, o listener é responsável por inserir/remover/ler os componentes.

Hummm … IoC tipo 1 obriga a usar a interface (pq é chamado de Interface Injection) mas o esquema do components.xml é como o Webwork escolheu pra ser configurado.

Esse é um problema sem solução elegante :shock: .

Como o WW usa o ComponentManager não é facil vc verificar se o usuário está logado diretamente na VIEW (JSP, VM , whatever) e o framework não faz isso pra você.
Na verdade a view não deve ter nada sem antes ser executada uma action e pra validar na action existe o filtro mas se vc quiser pode criar um ServletFilter mesmo trabalhando com o ComponentManager ou na view trabalhar com ele.

[]s

Muito Obrigado Smota, ajudou bastante.
Sobre o Initializer, eu imaginei mesmo que era algo em relação ao Tomcat e não ao WW, e não conhecia a Tag <load-on-startup>.

Sobre os listeners e o filter eu perguntei, pois eu fiz um teste parecido com o seu login, sem utilizar essas tags e funcionou normal.

“smota”:

Ueba … vamos por parte, como o Jack.
Como o WW usa o ComponentManager não é facil vc verificar se o usuário está logado diretamente na VIEW (JSP, VM , whatever) e o framework não faz isso pra você.
Na verdade a view não deve ter nada sem antes ser executada uma action e pra validar na action existe o filtro mas se vc quiser pode criar um ServletFilter mesmo trabalhando com o ComponentManager ou na view trabalhar com ele.
[]s

Agora essa parte eu viajei legal :oops: , não entendi muito bem qual solução você me propôs nesse caso :oops: :oops: