No caso do classificados, tô começando a achar que um filtro "povoador" antes de cada ApplicationController vai resolver melhor que a automação do beanutils.
Vai perder aquela sofisticação de "padrão" pois cada filtro vai ter seu próprio código e alguma coisa vai ser replicada, mas vai ganhar em desempenho e segurança. valeu, Felipe Gaúcho On Fri, 28 Jan 2005 09:27:32 -0300, rubens <[EMAIL PROTECTED]> wrote: > > > Usando o beanutils a conversão será feita, mas caso haja algum tipo de > conversão errada, uma exceção será lançada e o processo de conversão é > interrompido. O retorno do método 'populate' é void. > > > > Perhaps the biggest problem is that the RequestProcessor calls populate() on > the BeanUtils > > class instead of directly calling its setProperty() method. The populate() > method simply iterates > > a Map of request values and calls setProperty() for each non-null key. The > problem is that > > if a ConversionException is thrown during the call to setProperty(), the > iteration is short-circuited > > because populate() doesn't catch the exception. And even if it did catch > ConversionExceptions, > > there would be no way to provide information to the calling method about > failed > > conversions because the return type is void. > > > > Ou seja, pra não perder tempo, você pode refazer o método populate do > beanutils de forma que esta dê um feedback das conversões que deram erradas. > > Exemplo: > > ActionErrors populate(Object bean, Map map) > > > > Dessa forma, o que deu pra converter foi convertido, e o que não deu certo > vc sabe pelo retorno. > > > > -----Mensagem original----- > De: Felipe Vieira Silva [mailto:[EMAIL PROTECTED] > Enviada em: sexta-feira, 28 de janeiro de 2005 09:08 > Para: discussao@cejug.org > Assunto: Re: ENC: [cejug-discussao] experiências mais interessant es com > core-servlet > > > > Ok, > > > > bom saber que as dúvidas são compartilhadas por quem tem > > coragem/paciência de abrir o capô do struts :) > > > > Sim, um pouco mais além: > > > > No formulário de publicação de anúncios de emprego, o usuário será > > convidado a marcar os conhecimentos desejáveis dos candidatos. Essa > > lista de conhecimentos será dinâmica, ou seja, no init do > > FrontController será feito uma consulta ao banco para recuperar a > > tabela de "skills" - e o conteúdo desta tabela poderá mudar com o > > tempo. > > > > Ou seja, eu terei um conjunto dinâmico de caixas de seleção que > > deverão virar uma lista no Bean. > > > > Como fazer para converter de n-campos do formulário para uma lista no bean? > > > > Imagino que após o uso do beanutil, eu deverei fazer essa "conversão" > > na mão - é isso ? > > > > * Estou anexando o formulário atual dos classificados, apenas para > > ilustrar. E claro, a coisa toda está em fase de prototipação > > pré-modelagem - um tipo de prova de conceito. > > > > valeu, > > > > Felipe Gaúcho > > > > > > > > > > > > On Fri, 28 Jan 2005 08:55:37 -0300, rubens <[EMAIL PROTECTED]> wrote: > > > Gaúcho, > > > O Struts faz uso do commons beanutils para popular seus > > > ActionForms(DynaActionForms) extraindo parâmetros do request e populando > > > as propriedades desses beans. IMHO, o problema principal é que quando a > > > conversão(de uma string para o tipo especificado no bean) não dá certo, > > > o valor é perdido e não existe um tratamento de exceções que se possa > > > acoplar a esse modelo. Outro problema é que o bean nesse caso tem que > > > ser específico, ou seja, deve possuir métodos 'setXXXX' para cada > > > propriedade. > > > E no caso de se implementar um TO genérico, o beanutils não se aplica. > > > > > > Veja uma solução para essa deficiência: > > > http://www.theserverside.com/articles/content/StrutsLiveCh10/Chapter10-T > > > SS.pdf > > > > > > A outra solução seria implementar um framework ou API para: > > > - fazer conversões automáticas string para o tipo real. > > > - especificar um esquema de tratamento de exceções nessas conversões. > > > > > > Pensando mais além: > > > - formatação de dados dos beans para a camada de apresentação. > > > - geração de beans genéricos populados com dados de teste via arquivo > > > XML(DBUnit) para o auxílio em testes unitários. > > > - etc. > > > > > > -----Mensagem original----- > > > De: Ivan Romero Teixeira [mailto:[EMAIL PROTECTED] > > > Enviada em: sexta-feira, 28 de janeiro de 2005 08:28 > > > Para: discussao@cejug.org > > > Assunto: RES: [cejug-discussao] experiências mais interessantes com > > > core-servlet > > > > > > Gaucho, > > > descobri não faz muito tempo o commons-beanutils (bem, já > > > conhecia a > > > biblioteca mas nunca tinha me dado ao trabalho de estudar sua API) e > > > agora > > > estou fazendo uso intensivo dela. Vale só lembrar que a maior parte do > > > componente é baseada em reflexão da linguagem, e que se for usada para > > > muitos dados pode ter um impacto na performance da aplicação. > > > No seu caso vc pode usar da seguinte forma: > > > > > > BeanUtils.populate(new MyBean(),request.getParameterMap()); > > > > > > Bem, os nomes dos parâmetros da requisição devem bater com o do > > > Bean. Se houver parâmetros a mais serão ignorados. Se houverem > > > propriedades > > > no Bean que não existem no request estas permanecerão com seus valores > > > default. > > > Acho que ele resolve qualquer problema de case, mas testa aí e > > > diz > > > no que deu. > > > []'s! Ivan R. Teixeira > > > > > > -----Mensagem original----- > > > De: Felipe Vieira Silva [mailto:[EMAIL PROTECTED] > > > Enviada em: quinta-feira, 27 de janeiro de 2005 21:19 > > > Para: discussao@cejug.org > > > Assunto: [cejug-discussao] experiências mais interessantes com > > > core-servlet > > > > > > Aos que estão acompanhando a saga dos classificados CEJUG, aí vai uma > > > questão um pouco mais sofisticada: > > > > > > - Recebo um POST do cliente contendo um formulário. > > > - Tenho que povoar um Bean com os dados do formulário > > > > > > Opções: > > > > > > 0) deixar o struts esconder essa parte de mim (ainda não, depois :) ) > > > 1) criar um Bean específico para cada formulário (pode ser, mas quando > > > o número de páginas aumentar, a manutenção pode se tornar complicada) > > > 2) usar "Bean Introspection" em um Filter que está entre a camada de > > > apresentação e o FrontController. Este filtro teria a capacidade de > > > gerar um bean a partir do formulário, independente da quantidade e > > > tipo dos campos do formulário. (sofisticado e trabalhoso, porém um > > > desafio interessante - eu acho :) ) > > > > > > A idéia é permitir que o filtro preencha um ben e repasse ao > > > FrontController, que por sua vez irá identificar o tipo de requisição > > > e passar para o Helper este "bean genérico". O Helper confere/valida > > > os dados do bean e dispara o Command, que irá finalmente executar a > > > regra de negócio associada ao bean e retornar a próxima página.... O > > > Helper pode também fazer um casting do bean genérico para o bean > > > específico do serviço, para otimizar as próximas etapas... > > > > > > Comecei a olhar como fazer e, por sugestão do Régis, estou mexendo no > > > pacote "org.apache.commons.beanutils". > > > > > > pergunta: Alguém já usou o beanutils para criar beans a partir de > > > formulários JSP ? > > > > > > valeu, > > > > > > Felipe Gaúcho > > > > > > ------------------------------------------------------------------------ > > > ---- > > > --------------- > > > > > > 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] > > > > > > ------------------------------------------------------------------------------------------- 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]
