| Autor |
Mensagem |
|
|
Ok Lavieri, agora tá mais claro o que você quis dizer 
Lavieri wrote:eu me deparei com esse problema no redirect também, só estou relatando que provavelmente o problema é no redirect do views, pois quando faço redirect manual nas minhas pagina não encontro esse problema...
Fica a informação pros desenvolvedores então, ou pra quem tiver tempo e vontade de fixar. Garcia-jj, acho que o FLASH nada mais é do que colocar na session e remover após a requisição seguinte. Até tentei rapidamente acessar a session pra remover manualmente, mas não consegui. Além disso acho que eu ia ter que fazer isso no JSP, não ia ficar legal.
|
 |
|
|
Lavieri wrote:acho que vc não entendeu a minha colocação
Lavieri wrote:se vc irar os redirect do views funciona...
# produto.adiciona.ok = redirect:produto.lista.logic
# produto.atualiza.ok = redirect:produto.lista.logic
# produto.remove.ok = redirect:produto.lista.logic
# produto.recupera.ok = redirect:altera.jsp
mude para
# produto.adiciona.ok = produto.lista.logic
# produto.atualiza.ok = produto.lista.logic
# produto.remove.ok = produto.lista.logic
# produto.recupera.ok = altera.jsp
Sua colocação foi bem clara: remover o redirect que ia funcionar. Não só não vai funcionar, como também não tem sentido.
Sobre esse outro post mais novo, desculpa mas tá bem difícil de entender. Poderia abordar o exemplo fornecido? Você já leu isso? Sua versão é a 2.6?
|
|
|
|
Na verdade estou apenas treinando. Tem um projeto vindo que talvez eu use, se for o caso vou partir para a 3 direto. Mas po, seria bom consertar os bugs na série 2 também né
O que eu acho mais estranho é o relato no fórum do VRaptor de maio de 2008, dizendo que conseguiu fazer funcionar. Será que era a versão 1? Tirando isso, dá a entender que ninguém usa esse FLASH 
|
|
|
|
|
Lavieri, o escopo FLASH é justamente para uso com redirects
|
|
|
|
|
Atualizei pro 2.6.0 e nada... Parece bug mesmo.
|
|
|
|
lucas_mnzs wrote:pra mim o MVC é um padrão que divide o ponto de interação do sistema afim de isolar suas tecnologias visando uma maior portabilidade e melhor manutenção
Correto, sendo que o MVC dá nome aos bois, ou seja, você está dizendo explicitamente quais são esses pontos de interação. Quando você fala de camadas, está apenas falando de níveis de abstração de uma mesma informação, ou seja, é um conceito mais genérico. Por exemplo, um registro no banco de dados, que depois se torna um objeto Java em outra camada, que depois se torna dados formatados numa JSP. São as mesmas informações, mas em camadas diferentes.
Eu costumo ver o MVC da seguinte forma: o Model é simplesmente o seu modelo, ou domínio, ou regras de negócio. A View é a apresentação desse modelo ao usuário. Você poderia ter views diferentes para o mesmo modelo: poderia haver uma interface web usando JSP como view, e outra desktop usando Swing, por exemplo. Separar as responsabilidades conforme o MVC ajuda a implementar esse tipo de coisa.
Porém, a View e o Model por si só não funcionam: se você desenhar uma tela para adicionar um cliente, e a classe de domínio correspondente, isso por si só não vai permitir que você realize a operação. É preciso algo que realmente reaja aos eventos da View, manipulando as regras de negócio para devolver um resultado. É aí que entra o Controller, que nada mais é do que o cara que "dá vida" à View e ao Model. Numa aplicação desktop, fazem parte dele os manipuladores de eventos por exemplo, já numa aplicação web poderíamos citar os servlets e as actions dos frameworks. Enfim, gosto de pensar no Controller como tudo que manipula ou "dá vida" à View e ao Model.
Quanto à MVC ser camadas ou não, no meu entender a View é um nível de abstração do Model. Uma tela de cadastro de produto é a interface para acessa a classe de domíno, que depois vai se tornar um registro no banco de dados. Em todas as fases estamos falando da mesma informação, o produto, mas em níveis de abstração, ou camadas, diferentes. Já o Controller eu não gosto muito, de acordo com o exposto, de pensar como camada.
Uma observação: as classes de persistência no MVC se encaixariam no Model ou ainda, abaixo dele, como uma camada se suporte.
|
|
|
|
|
Socorro!
|
|
|
|
Deixando um pouco de lado os últimos termos da moda, não acho que deixar os objetos de negócio cientes da camada de persistência necessariamente indique um entendimento errado do domínio. Do contrário o que dizer (voltando aos termos da moda) das aplicações usando ActiveRecord? Estariam todos com prováveis problemas de modelagem? A persistência dos objetos é um problema de implementação da aplicação, e não do domínio, e ao meu ver, é possível sim um mesmo domínio ser implementado com uma abordagem ou outra.
|
|
|
|
A documentação não cita o @In como necessário para o escopo FLASH. Além disso, no fórum um usuário removeu o @In para fazer funcionar. Mesmo assim, já havia tentando isso que você postou, mas não funciona. Só pra constar aqui estão os arquivos:
ProdutoLogic:
altera.jsp:
views.properites:
|
|
|
|
Não de acordo com a documentação.
Mas enfim, o @In e @Out ficariam onde exatamente? Tentei de alguns jeitos e nenhum deles funcionou.
Será possível que ninguém passou por este problema? 
|
|
|
|
|
Se você já resolveu então deixa. O index configura no web.xml.
|
|
|
|
Ok, o lance das aspas é porque sem elas o hsqldb converter para maiúsculo, pensei que fosse esse o problema.
Agora uma curiosidade, como você consegue gravar os registros no disco? Quando eu tentei usar ele só mantinha os dados na memória, tentei o shutdown=true na string de conexão mas não funcionava...
|
|
|
|
|
Cara, posta aqui o arquivo .settings/org.eclipse.wst.common.component
|
|
|
|
Tenta isso:
|
|
|
|
|
É so mudar pra session que funciona! Estou usando EL na JSP.
|
|
|
|