not quite .. when i arrive initially at the view governed by somePage.jsp yes, there are a bunch of request attributes set up. on this page is my form. as a hidden variable to the form I copy the existing page id because this must be present for our SecuredBaseAction to know what properties to load into the "new" request.
what i see as completely possible and useful is that for a DynaActionForm action's input="somePage.jsp" attribute, to use input="anActionExtendingSecuredBaseAction.do" so that when validator fails the form, it can call the action which can make sure to lookup the page id from the dyna form, query the backend for the attributes, whack them into the request and then return a view. do you see what i mean :)) > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
