> Now, my understanding was that DynaActionForm manages to populate a map of > form fields, match them up against validation rules, and if it fails, it > would KEEP the previous request but add errors into it and FORWARD back to > the view, therefore KEEPING all the request attributes. It does not appear > to work in this manner and I am confused.
I think you are confusing what is happening here. If I understand you correctly, you are setting thing into the request, then forwarding to a "somePage.jsp" page. When the user submits that page, and the validator fails, the request is forwarded to the input="somePage.jsp" of that action mapping. And you are wondering why those attributes you set in the first request are not there for the second on? Am I understanding you here? If yes, then you should know that those are 2 separate requests. If you rely on some collection to be in the request for use with a select box, that collection won't be there if the validator fails. As I understand it, you don't want to store thing in the session. That's ok, there are many different approaches to get around this. If you ask 5 developers, you'll likely get 6 different answers. You should Google it, and/or buy a book. I would recommend that new one coming out by O'Reilly. Bill Siggelkow is one smart cookie (when sober ;). -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx ----- Original Message ----- From: "Allistair Crossley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 17, 2004 7:00 AM Subject: DynaActionForm and previous request attributes (no answer found in archives for similar problems) Hi All, I am coming up against a limitation of using DynaActionForm that I wonder if someone can confirm or deny. All our Action classes extend a SecuredBaseAction. This SecuredBaseAction does a few important things per request like making sure the user is validated and also loading page properties matching a page id that is assigned to each request so that when the Action returns the view, that view is able to do stuff like build the navigation and a range of other things I won't bore you with. This is an intranet system therefore navigation needs to be present at all times and so on. This is a per request attribute and so it should be. Now, I am building a validator-based application that sits within this intranet framework. I do not want to get into ActionForms as they are a ball-ache but I do like the validator framework, so I want to use DynaActionForms. I have setup my first form and have it validating without an issue. However, there is an issue because when I get my input view back following a failure, all my request attributes are gone from the previous request and because I have to send a forward, my nav attributes and so on cannot be reloaded. This is causing errors. Now, my understanding was that DynaActionForm manages to populate a map of form fields, match them up against validation rules, and if it fails, it would KEEP the previous request but add errors into it and FORWARD back to the view, therefore KEEPING all the request attributes. It does not appear to work in this manner and I am confused. A similar post I found suggests using SESSION but this is not only poor practice but impossible for the operations we need to perform per action. Any comments are greatly appreciated else I am going to have to scrap using validator which I don't want to do. Cheers, ADC. <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> ------------------------------------------------------- QAS Ltd. Developers of QuickAddress Software <a href="http://www.qas.com";>www.qas.com</a> Registered in England: No 2582055 Registered in Australia: No 082 851 474 ------------------------------------------------------- </FONT> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
