WebWork - Gravando sessão na action

JavaEvangelist Membro desde: 07/07/2006 12:28:12 Mensagens: 393 Offline

Gostaria de Saber como faço para criar uma sessão dentro de uma action??

Valeu!!!!

Acho que não entendi bem o que você quis dizer com "criar uma sessão dentro de uma ação"...mas bem. Uma ação pode acessar a sessão atual da seguinte maneira:

- Faça sua ação implementar a interface com.opensymphony.webwork.interceptor.SessionAware
- Com isso você deverá implementar o método setSession(Map) para armazenar a seção (que, suponho, é o que você precisa)
- Modifique a entrada da sua ação no xwork.xml para incluir o interceptor servlet-config (o que acontece se você usar a defaultStack). Ou seja, inclua, na definição da sua ação, uma das duas linhas a seguir (incluir as duas é redundante):

[]'s e boa sorte

Vai precisar de um boa sorte mesmo !!!

Com certeza isso deve ter mudado recentemente, pois fazer algo básico que é pegar uma session dessa maneira bastante simples e rápida aí é realmente inadmissível.

E coo vc invalida a session se ela é um map ???????????????

Acho que hoje em dia vc pega isso do contexto do webwork, sem interface enabler e essa papagaiada toda.

No mentawai a session já vem dentro de toda action, logo vc pode fazer assim em qualquer lugar da sua action:

E para resetar:

Repare que essa session aí é um org.mentawai.core.Context, assim como CookieContext, ApplicationContext, etc.

JavaEvangelist Membro desde: 07/07/2006 12:28:12 Mensagens: 393 Offline

Eu vi que é possivel criar uma classe UserSession e um interface UserSessionAware.
Depois eu adiciono os dois numa Classe SystemAction que extende um ActionSuporte, assim:

depois tem que criar um arquivo components.xml e mapear a classe UserSession e um interface UserSessionAware.

Mas parece que estou com problema no web.xml, que não está configurado certo.
Alguém já fez desse jeito ???

PS.:Obrigado pelas dicas!!

PS.:A opção de fazer com mentawai não é possivel , mas me parece interessante, principalmente porque estou tendo muitos problemas com configuração.

Tão simples quanto:

saoj wrote:Vai precisar de um boa sorte mesmo !!!

Ele só precisava fazer uma busca no Wiki do Webwork.

saoj wrote:Com certeza isso deve ter mudado recentemente, pois fazer algo básico que é pegar uma session dessa maneira bastante simples e rápida aí é realmente inadmissível.

E coo vc invalida a session se ela é um map ???????????????

saoj wrote:Acho que hoje em dia vc pega isso do contexto do webwork, sem interface enabler e essa papagaiada toda.

Sim, é verdade. E desde de que eu conheço o WebWorks (a muito, muito tempo)

saoj wrote:No mentawai a session já vem dentro de toda action, logo vc pode fazer assim em qualquer lugar da sua action:
User u = (User) session.getAttribute("user");
E para resetar:
session.reset();

Repare que essa session aí é um org.mentawai.core.Context, assim como CookieContext, ApplicationContext, etc.

O WebWork têm uma fisolofia diferente, o WebWork usa o framework XWork, que é um framework POJO de commands (pode ser utilizado em swing, JMS e diversas outras coisas). Por isso, toda action não têm necessáriamente tudo que um action web deveria ter, por que nem sempre essa action é web.

Se invez de usar action diretamente você importar DefaultActionSupport, você terá também um monte de métodos de suporte, inclusive continuation.

É sempre legal, você criar a sua própria classe ActionBase.

JavaEvangelist Membro desde: 07/07/2006 12:28:12 Mensagens: 393 Offline

Eu vi que é possível criar um objeto dentro da ActionSuprte como se fosse uma sessão, usando UserSession e UserSessionAware. Alguém conhece??

juzpeleteiro wrote:
Sim, é verdade. E desde de que eu conheço o WebWorks (a muito, muito tempo)

Eu já vi essa questão da session em diversos lugares feito com enablers, ioc, xml, etc.

Aqui mesmo no GUJ tem um tutorial que vai por esse caminho, por isso que eu achei que essa mudança para pegar a session do ActionContext tinha sido feito recentemente. (recentemente = a 1 ano atrás).

Quando vc diz que para invalidar a session vc faz:

Vc tem certeza que session.invalidate() está sendo chamada por trás ??????? Não é o que parece pois parece apenas que vc está criando uma nova Map. Mas o que aconteceu com o objeto HttpSession ? É obrigatório chamar invalidate para criar uma nova sessionId e para trigar callbacks como HttpSessionBindingListener.

Acho que session.reset() fica mais claro que tudo isso está acontecendo por trás dos panos.

E os cookies ????? Como vc trata cookie dentro de um map ? Se vc dá um clear no map todos os cookies serão removidos do browser ?

Deve ter workaround pra isso no webwork, com certeza. Mas o cara vai ter que sair procurando na documentação do webwork, que não é muito boa/clara/organizada.

Por isso que eu prefiro ter uma interface org.mentawai.core.Context implementada por CookieContext, ApplicationContext, SessionContext, QualquerCoisaContext.

http://www.mentaframework.org/api/org/mentawai/core/CookieContext.html

Doc API CookieContext wrote:
A cookie management abstraction into a Mentawai context. Note that this class is smart enough to keep track of which cookies were added, which ones were removed and which ones did not suffer any modification and should not be sent again to the browser.

O mentawai tb tem a interface Action, que vc pode implementar, mas 99.9% das actions de um projeto web só serão executads no projeto web. Essa de executar uma action em outro ambiente que não seja web é legal e o menta suporta, mas na prática é ignorada pois 99% não precisa ou quer fazer isso.

Assim como o webwork tem ActionSupport o mentawai tem BaseAction.

Mas mesmo quando vc herda ActionSupport vc ainda assim tem que usar o ActionContext e um bucado de enablers. Sim o webwork só faz IoC via enablers. Não sei agora como ficou depois da integração com o spring.

Bom, isso é apenas um comparativo rápido sobre algumas pequenas diferenças entre webwork e mentawai. Nada muito crítico que torne o webwork um framework ruim, muito pelo contrário. O webwork é um ótimo framework web. Apenas acreditamos que o mentawai é muito, mas muito mais simples que o webwork.

saoj wrote:O mentawai tb tem a interface Action, que vc pode implementar, mas 99.9% das actions de um projeto web só serão executads no projeto web. Essa de executar uma action em outro ambiente que não seja web é legal e o menta suporta, mas na prática é ignorada pois 99% não precisa ou quer fazer isso.

Sim, em um projeto web sim. Mas o XWork (que é utilizado pelo WebWork) é um framework genérico.

Assim como o webwork tem ActionSupport o mentawai tem BaseAction.

Mas mesmo quando vc herda ActionSupport vc ainda assim tem que usar o ActionContext e um bucado de enablers. Sim o webwork só faz IoC via enablers. Não sei agora como ficou depois da integração com o spring.

Bom, isso é apenas um comparativo rápido sobre algumas pequenas diferenças entre webwork e mentawai. Nada muito crítico que torne o webwork um framework ruim, muito pelo contrário. O webwork é um ótimo framework web. Apenas acreditamos que o mentawai é muito, mas muito mais simples que o webwork.

Sim, o WebWork é muito bom. Faz mais de uma ano que eu não mexo com ele, e não tenho acompanhado muito. Mas se eu fosse olhar para o WebWork como ele estava a 1 ano atráz diria que ele está meio ultrapassado. Mas olhando a documentação para responder esse post eu li até sobre suporte a Continuation (utilizando o continuation do Rife, percebi pelo nome do pacote) o que é beeeem legal.

Uma coisa eu acompanhei de perto, ate por ser commiter do PicoContainer, foi o suporte transparente ao Pico e Spring que foi implementado no WebWorks. Simplemente genial.

Embora XML sejá o mais utilizado, saiba que o WebWork (assim como Spring e o Pico) suportam configuração programatica. Eu inclusive já utilizei uma vez no WebWork (aonde configuração programatica foi vantajoso para mim). (Por favor, não me peça por exemplo, faz muuuuuuito tempo).

Uma coisa eu acompanhei de perto, ate por ser commiter do PicoContainer, foi o suporte transparente ao Pico e Spring que foi implementado no WebWorks. Simplemente genial.

Isso vai ser bom para o webwork, pois acho que era consenso que o suporte do webwork a IoC e DI não era bom. Enablers pra tudo, xml, impossibilidade de reutilizar variantes de um mesmo componente sem ter que criar outro componente (e outro enabler com mais xml), injeção apenas em setter, etc.

O suporte do menta a IoC e DI ainda pode melhorar, principalmente documentação e cookbook, mas está bastante legal e totalmente transparente, mais ou menos como o PicoContainer.

Acho que vc poderia dar uma dicas, já que vc é committer do PicoContainer.

Link sobre WebWork x Spring em relacao a IoC: http://www.theserverside.com/news/thread.tss?thread_id=21962

saoj wrote:

Uma coisa eu acompanhei de perto, ate por ser commiter do PicoContainer, foi o suporte transparente ao Pico e Spring que foi implementado no WebWorks. Simplemente genial.

Isso vai ser bom para o webwork, pois acho que era consenso que o suporte do webwork a IoC e DI não era bom. Enablers pra tudo, xml, impossibilidade de reutilizar variantes de um mesmo componente sem ter que criar outro componente (e outro enabler com mais xml), injeção apenas em setter, etc.

Não era mesmo não, mas agora está chuchu beleza.

saoj wrote:O suporte do menta a IoC e DI ainda pode melhorar, principalmente documentação e cookbook, mas está bastante legal e totalmente transparente, mais ou menos como o PicoContainer.

Acho que vc poderia dar uma dicas, já que vc é committer do PicoContainer.

Sim, claro. E só você perguntar. Mas não ache eu sou um gênio em IoC não, que estou longe disso. Só que eu usava muito o Pico e queria ver algumas coisas implementadas nele, fui lá e implementei. (suporte a Hibernate3, DataSource, Webservices e NanoWeb).

Para mim o grande beneficio de um container e o controle do ciclo de vida de um componente (e nisso o Pico é fantástico) e AOP de forma transparente (e nisso o Spring 2.0 arrassa).

Também não sou. Peguei as idéias desse link que eu coloquei mais acima.

Quanto a ciclos de vida de um componente de IoC de um projeto web:

- Request: uma nova instancia é criada para cada novo request

- Session: uma nova instanciia é criada para cada nova session

- Application: uma instancia é criada para cada aplicacão e como aplicacao é uma só entao teremos apenas uma instancia

Existe outras possibilidades/cenarios para um componente de um projeto web ?

Ja quanto a AOP não posso falar pois não manjo nada...

saoj wrote:Também não sou. Peguei as idéias desse link que eu coloquei mais acima.

Quanto a ciclos de vida de um componente de IoC de um projeto web:

- Request: uma nova instancia é criada para cada novo request
- Session: uma nova instanciia é criada para cada nova session
- Application: uma instancia é criada para cada aplicacão e como aplicacao é uma só entao teremos apenas uma instancia

Existe outras possibilidades/cenarios para um componente de um projeto web ?

Sim, denominado hoje em dia de conversação, algo como o contexto de um conjunto de request. Como um wizard ou algo do tipo. O JBoss Seams e o Spring WebFlow implementam esse contexto de forma graciosa.

Isso é um ponto chave para perfomace de aplicações web hoje, você econimiza trafico de rede (você não precisa fica passando os parametros em toda requisição), conexão com banco de dados etc...

Com conversação você pode por exemplo está preenchendo dois formularos iguais (e com flow) em duas janelas separadas.

Um outro contexto é o que se chama de flash hoje (o primeiro lugar que eu vi isso foi no Raisl, e vários frameworks já estão implementando).

Que é um contexto que dura 2 requisições, ótimo para quando ocorre um erro e você invez de dar forward na tela de erro vc dá redirect, evitando assim refresh.

saoj wrote:Ja quanto a AOP não posso falar pois não manjo nada...

É bem interessante. Cuidado com o over AOP, mas AOP aonde aplicado ajuda em muito. Controle de transação, segurança, cache e otimização.

Hummmm. Interessante. Vamos pensar nisso....

A solucao padrão pra isso é ir guardando as coisas na sessão, mas concordo que esse esquemo é mais bonito e limpo, pois não polui a sessão e separa as coisas.

saoj wrote:Hummmm. Interessante. Vamos pensar nisso....
A solucao padrão pra isso é ir guardando as coisas na sessão, mas concordo que esse esquemo é mais bonito e limpo, pois não polui a sessão e separa as coisas.

Sim, mas é ineficiente. Imagine você tendo duas janelas do browser aberta ao mesmo tempo? Uma fonte de bugs em sistemas web é justamente essa.

Até da para contorna, gerando uma chave única e ficar passando ela entre as requisições... Mas é muito trabalho manual, prefiro como é no seam

Pronto, essa session do hibernate está no scopo da conversação.

Ou então

Pronto, o Bean cliente que é preenchido automaticamente pelos parametros dos requests são mantidos durante toda a conversação.

Existem ainda outros scopos, de uma olhada em http://docs.jboss.com/seam/latest/api/org/jboss/seam/ScopeType.html para ver alguns.

Notícias, artigos e o maior fórum brasileiro sobre Java