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]
