n�o sei se o filter pega o contexto... o meu bean fica no request, porque ele � um para cada servi�o que o usu�rio quer executar na aplica��o web... E o Filter tem acesso ao request...
sim, voc� pode mapear no web.xml quais os "paths" que ir�o ser filtrados - pode ser mais de um. Veja um exemplo em: https://cejug-classifieds.dev.java.net/source/browse/cejug-classifieds/web-app/WEB-INF/src/net/java/dev/cejug/classifieds/filter/JobPublisherFilter.java que � mapeado no web.xml da seguinte forma: <filter> <filter-name>JobPublisherFilter</filter-name> <filter-class>net.java.dev.cejug.classifieds.filter.JobPublisherFilter</filter-class> </filter> <filter-mapping> <filter-name>JobPublisherFilter</filter-name> <url-pattern>/jobPublisher.do</url-pattern> </filter-mapping> Voc� pode encontrar o web.xml em: https://cejug-classifieds.dev.java.net/source/browse/cejug-classifieds/web-app/WEB-INF/web.xml se tiver tempo e paci�ncia, sugiro que tu baixe o projeto e veja funcionando.. sinta o comportamento das classes, at� debugando no eclipse pra facilitar a compreens�o do que n�s fizemos... E se tiver alguma contribui��o, a equipe agradece muito :) valeu, Felipe Ga�cho On Wed, 23 Feb 2005 14:33:38 -0300, Marcelo Pinheiro <[EMAIL PROTECTED]> wrote: > A� Felipe, > > n�o seria legal colocar o bean no contexto como sugeriu o Philip por > que os valores podem alterar no decorrer da aplica��o e isso gera > inconsist�ncia . > Eu t� usando o struts aqui ele j� implementa os padr�es > FrontController e o Command, > Estou meio confuso em rela��o a onde exatamente no struts eu colocaria isso. > Em um filter(Tem como obter o request no filter?)?e no web.xml eu > mapear as paginas que podem usar esse filter? > > On Wed, 23 Feb 2005 14:09:49 -0300, Felipe Vieira Silva > <[EMAIL PROTECTED]> wrote: > > no cejug-classifieds, adotamos o padr�o Filter para fazer isso... > > > > temos umas taglibs que fazem a parte visual, mas o controle dos > > valores que o usu�rio j� selecionou e a c�pia destes valores para os > > respectivos beans � feita pelos filtros.. > > > > 1 filtro asssociado a cada Helper e 1 helper instanciado 1 command > > para cada caso de uso... > > > > o fluxo ficou assim: > > > > 1 - o usu�rio chama a aplica��o via FrontController > > 2 - o FrontController passa para o HelperFactory a requisi��o > > 3 - o HelperFactory retorna o objeto Helper que ir� lidar com a > > requisi��o. A partir da� o helper decide o fluxo de controle a partir > > do tipo de requisi��o: > > > > 3.1 - se for primeira chamada (GET), o helper gerencia o retorno do > > JSP com a interface de suporte � requisi��o (um formul�rio, etc.). > > Simplesmente faz um redirect.... > > > > 3.2 - se for o POST de um formul�rio, o Helper instacia o comando > > que tem a regra de neg�cio associada � requisi��o e chama o m�todo > > "execute(bean);", passando o Bean preenchido com os dados do > > formul�rio como par�metro. O Command retorna um objeto CommandResult, > > que tem detalhes da execu��o e um valor booleano de status: sucesso ou > > fracasso. > > > > 4 - Se o command precisar recuperar ou atualizar valores no banco, > > pede o DaoFactory um DAO relativo � tabela que ele vai usar e passa a > > este DAO os valores do bean... > > > > OBS: o fluxo de controle s� chega ao Helper caso os filtros que > > validem a requisi��o .. Os filtros atuam independentes do > > FrontController e est�o mapeados aos servi�os no web.xml. > > > > � por a�... > > > > mas lembra que isso foi s� uma implementa��o baseada em padr�es.. tal > > qual o struts, o springer e muitas outras... tudo isso pode ser > > revisto ou contestado... > > > > > > On Wed, 23 Feb 2005 13:54:52 -0300, Marcelo Pinheiro > > <[EMAIL PROTECTED]> wrote: > > > na minha aplica��o eu tenho alguns beans que dever�o ser apresentados > > > em Select(combobox) em varios locais da minha aplica��o,onde seria o > > > melhor local pra eu popular esses selects? > > > Colocar todos na sess�o??(N�o gosto muito dessa ideia..) > > > ficar acessando sempre o banco?(deve perder performance...) > > > alguem tem alguma ideia? > > > > > > ------------------------------------------------------------------------------------------- > > > Ceara' Java User Group > > > > > > Para cancelar sua assinatura, envie um e-mail para: [EMAIL PROTECTED] > > > Para mais informacoes, mande um e-mail para: [EMAIL PROTECTED] > > > Falar com o administrador? e-mail para: [EMAIL PROTECTED] > > > > > > > > > > ------------------------------------------------------------------------------------------- > > Ceara' Java User Group > > > > Para cancelar sua assinatura, envie um e-mail para: [EMAIL PROTECTED] > > Para mais informacoes, mande um e-mail para: [EMAIL PROTECTED] > > Falar com o administrador? e-mail para: [EMAIL PROTECTED] > > > > > ------------------------------------------------------------------------------------------- Ceara' Java User Group Para cancelar sua assinatura, envie um e-mail para: [EMAIL PROTECTED] Para mais informacoes, mande um e-mail para: [EMAIL PROTECTED] Falar com o administrador? e-mail para: [EMAIL PROTECTED]
