RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
Well, validate=false is now on my action and in the code is
DynaValidatorForm dynForm = (DynaValidatorForm) form;
ActionErrors dynFormErrors = dynForm.validate(mapping, request);
if (! dynFormErrors.isEmpty()) {
logger.debug(invalid form);
saveErrors(request, errors);
return mapping.findForward(VIEW_CREATE_STEP1);
}
but the validation here is not working, i.e with the data I am submitting the above
block should be run but it is skipped because no errors are present.
Using this manual mechanism with DynaActionForm, will validate(mapping, request) still
tie up with the declarative validator-rules.xml/validate.xml files?
ADC
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: 18 September 2004 20:00
To: Allistair Crossley
Subject: Re: DynaActionForm and previous request attributes (no answer
found in archives for similar problems)
Emailing you off list as well. Make you check out the bottom of this
page. It'll solve your problem.
Don't validate automatically. Manually validate in your
Action. Example
here: http://www.reumann.net/struts/articles/request_lists.jsp
--
Rick
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
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
Allistair Crossley wrote the following on 9/20/2004 6:12 AM: DynaValidatorForm dynForm = (DynaValidatorForm) form; ActionErrors dynFormErrors = dynForm.validate(mapping, request); I just tested this and it works fine. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
Allistair Crossley wrote the following on 9/17/2004 8:40 AM: however, because I am forced to use a tile definition or JSP in the input parameter of the action for when the validation fails, i am unable to load page attributes for that pid from my backend navigation system and this is breaking my view. Don't validate automatically. Manually validate in your Action. Example here: http://www.reumann.net/struts/articles/request_lists.jsp -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
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]
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
I would agree with him. I can suggest you the same. Jitender Kumar C.V.
RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
but that's bad practice. very bad. -Original Message- From: Jitender K Chukkavenkata [mailto:[EMAIL PROTECTED] Sent: 17 September 2004 12:51 To: Struts Users Mailing List Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) I would agree with him. I can suggest you the same. Jitender Kumar C.V. 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]
RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
what I have already described in some detail. the use of base actions is a good pattern to use as one can group common behaviour into them, such as authentication or ensuring other properties. in our case we do both, security AND ensuring some session lists for user (i.e those things that make sense to be in session because they don't change often at all for the lifetime of a user's visit) but also request attributes as I said .. the user clicks a nav link, that page's attributes get loaded as a map, and do not make sense to be in the session because it is per-request object. now, my issue with DynaActionForm is that it ought to relise that if it has to forward the user page to the page they came from, it ought to also forward the request values back, OR at least be able to give you the opportunity to specify an Action rather than an ActionForward as the input parameter so that we can ensure those request vars are present for the view. managing a request attribute in the session by setting it and then making sure we pop it out at the view is messing and defies the semantic use of the request scope. that's why it is bad practice. ADC -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: 17 September 2004 13:02 To: Struts Users Mailing List Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) What is 'bad practice'? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 17, 2004 7:58 AM Subject: RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems) but that's bad practice. very bad. -Original Message- From: Jitender K Chukkavenkata [mailto:[EMAIL PROTECTED] Sent: 17 September 2004 12:51 To: Struts Users Mailing List Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) I would agree with him. I can suggest you the same. Jitender Kumar C.V. 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]
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
how to invalidate the session when user clicks the close(cross) button which will display at the right side of the browser when we open a page.. On Fri, 17 Sep 2004 08:01:45 -0400, James Mitchell [EMAIL PROTECTED] wrote: What is 'bad practice'? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 17, 2004 7:58 AM Subject: RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems) but that's bad practice. very bad. -Original Message- From: Jitender K Chukkavenkata [mailto:[EMAIL PROTECTED] Sent: 17 September 2004 12:51 To: Struts Users Mailing List Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) I would agree with him. I can suggest you the same. Jitender Kumar C.V. 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] -- Kranti Kiran Kumar Parisa Software Engineer [ e-Biz ], Patni Computer Systems Ltd., India Mobile: +91 98504 45977 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
managing a request attribute in the session by setting it and then making sure we pop it out at the view is messing and defies the semantic use of the request scope. that's why it is bad practice. Don't shoot me if I'm wrong but HTTP is stateless so without any of: cookie, session, browser politeness (HTTP referer), hidden field with url, server won't be know where you come from (and in request scope you will won't have any information where user was before clicking Submit) ... Regards, Adrian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
You can put JavaScript on every page that will attempt to send the browser to a specific url when the browser is closing, but that would be browser specific and it is VERY likely that your action will never get called for most users. This is the web, if you want that feature you will need to go rich client. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Kranti Parisa [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 17, 2004 8:09 AM Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) how to invalidate the session when user clicks the close(cross) button which will display at the right side of the browser when we open a page.. On Fri, 17 Sep 2004 08:01:45 -0400, James Mitchell [EMAIL PROTECTED] wrote: What is 'bad practice'? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Allistair Crossley [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 17, 2004 7:58 AM Subject: RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems) but that's bad practice. very bad. -Original Message- From: Jitender K Chukkavenkata [mailto:[EMAIL PROTECTED] Sent: 17 September 2004 12:51 To: Struts Users Mailing List Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) I would agree with him. I can suggest you the same. Jitender Kumar C.V. 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] -- Kranti Kiran Kumar Parisa Software Engineer [ e-Biz ], Patni Computer Systems Ltd., India Mobile: +91 98504 45977 - 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]
RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
when i submit my form to the action, the action maps my form to a DynaActionForm and binds the values. now, along with my form, i actually do submit something called PID (page id) which is the current page at time of submission. therefore, my dyna form will have the page id for which i need to load navigational information. however, because I am forced to use a tile definition or JSP in the input parameter of the action for when the validation fails, i am unable to load page attributes for that pid from my backend navigation system and this is breaking my view. now you might say that all i need to do is load the page attributes from the jsp because it will be in the dyna form when i get to the view after failure, but now we are talking about breaking the whole point of MVC as i would need to call my backend. can anybody see what i am getting at here? -Original Message- From: Adrian Kaminski [mailto:[EMAIL PROTECTED] Sent: 17 September 2004 13:33 To: Struts Users Mailing List Subject: Re: DynaActionForm and previous request attributes (no answer found in archives for similar problems) managing a request attribute in the session by setting it and then making sure we pop it out at the view is messing and defies the semantic use of the request scope. that's why it is bad practice. Don't shoot me if I'm wrong but HTTP is stateless so without any of: cookie, session, browser politeness (HTTP referer), hidden field with url, server won't be know where you come from (and in request scope you will won't have any information where user was before clicking Submit) ... Regards, Adrian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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
RE: DynaActionForm and previous request attributes (no answer found in archives for similar problems)
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]
