Hi, I think there is some misconfiguration issue, as far as I know, there are two kind of actions in Struts, EditXXXXAction and SaveXXXXAction. For my implementation, all the EditXXXXAction have validate=false in the struts-config.xml and all the SaveXXXXAction have validate=true.
EditXXXXAction took care of 2 operations, edit and add, for add, it just instantiate an object, for edit operation, it have to load the values from the persistence layer (loading from JSP is surely a very ugly thing to do.). So for EditXXXXAction, its just plainly creating and loading, no validation is neccessary, for SaveXXXXAction, then we need validation. CHeers, Yee Keat ----- Original Message ----- From: "Robert Scaduto" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Feb 6, 2002 2:31:19 AM GMT+08:00 Subject: RE: Design question about ActionForm's validate method >Matt, > >I also disagree that you should only use actions when submitting a form. I >also believe that in most cases you should never forward a request directly >to a jsp without first going through the Action framework. > >Struts provides a utility action that will do this for you. The >org.apache.struts.actions.ForwardAction will forward to the jsp file >specified in the parameter attribute of the action mapping. Like so.. > ><action path="/passwordAssistance" > type="org.apache.struts.actions.ForwardAction" > parameter="/password_assistance.jsp"> ></action> > >If you are using the *.do extension in your servlet mapping you would access >the action like this... > ><html:link page="/passwordAssistance.do">Go to Password >Assistance</html:link> > >It may seem like extra work for no reason but if the requirements of your >system change and now you need to forward to an action instead of a jsp it >is much easier to replace the ForwardAction to a custom action. > >It sounds to me like you are on the right track. > >-Rob > >-----Original Message----- >From: Matt Read [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, February 05, 2002 12:59 PM >To: Struts Users Mailing List >Subject: RE: Design question about ActionForm's validate method > > >I'm fairly new to struts (well, about 24 hours actually) and this message >touches on a concept that I've having trouble grasping. > >Are you saying that your site should never allow the user to navigate to a >URL that maps to an Action unless you are submitting a form? > >This is my example and although it's actually working in practice it doesn't >really feel right to me and doesn't conform to above rule. I hope I've >included enough detail and would appreciate any clues on good design. > >1. User goes to the home page and clicks on a "Find a client" link. >2. This link points to "/find/client.do" which is defined as an >ActionMapping as follows: > <action path="/find/client" > type="mysite.actions.FindClientAction" > name="clientFindForm" > scope="request" > input="/pages/findclient.jsp"> > <forward name="newsearch" path="/pages/findClient.jsp"/> > </action> >3. The code in FindClientAction ensures that the user is authenticated and >then populates some request scoped attributes that enabled >/pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a >form to allow the user to enter search criteria. >4. The submit action for the form in /pages/findClient.jsp is >"/find/getresults" which is defined as an ActionMapping as follows: > <action path="/find/clientresults" > type="mysite.actions.FindClientResultsAction" > name="clientFindForm" > scope="request" > input="/pages/findclient.jsp"> > <forward name="success" path="/pages/findClientResults.jsp"/> > </action> >5. The code in FindClientResultsAction examines the contents of the >clientFindForm and contstructs a SQL statement to retrieve the correct data. >6. /pages/findClientResults.jsp renders the results from the database. > >Matt. > >-----Original Message----- >From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] >Sent: 05 February 2002 17:44 >To: Struts Users Mailing List >Subject: Re: Design question about ActionForm's validate method > > > >I made this same 'mistake'. > >Actions MUST only be called when a form is submitted. Never to generate >the JSP. Thats why they are called actions. > >Or two put it another way, you do need several URL's > >a) URL to JSP on a GET >b) URL to action the POST > >The easiert way to do it is to have all forwards going directly to the JSP, >and all actions in the pages going to xxxx.do. > >At first it seems rubish, but then you hopefully buy into the model view >controller idea. i.e NO business logic in the page and it all starts to >make perfect sence. But you really do have to buy into it otherwise you >are fighting urge to ditch it all and go back to brilliant servlets, nice >and easy, total power etc etc. > >Jonathan > > >---------------------------------------- Message >History ---------------------------------------- > > >From: Sid Stuart <[EMAIL PROTECTED]> on 05/02/2002 09:24 PST > >Please respond to "Struts Users Mailing List" ><[EMAIL PROTECTED]> > >To: Struts Users Mailing List <[EMAIL PROTECTED]> >cc: >Subject: Design question about ActionForm's validate method > > >Hi, > >I've stumbled across a subtle problem/design question that I don't see >mentioned in the documentation. > >The ActionForm's validate method can be configured to verify form data >from a page and generate error messages which may then be displayed on >the page for the user to see. This works fine when the user has accessed >the page by specifying a JSP file in the URL. When the user accesses the >page by calling the Action directly though, the validate method is >called before the user ever sees the page, much less inputs valid data >to the form. This leads to an unfortunate display of unwarranted error >messages. > >It would be nice if the documentation would provide a rule such as: >If one plans on the user calling the Action directly in the URL then >one should not use the automatic validation provided by ActionForm. > >Further, as having two different procedures to generate a page can lead >to subtle errors, one should decide whether a page will be accessed as a >JSP or as an Action and design for the one scenario. The simplest (and >safest) design rule will be to access all pages through either one >mechanism or the other. > >Comments? > >Sid Stuart > > > > > > > > >-- > >This e-mail may contain confidential and/or privileged information. If you >are not the intended recipient (or have received this e-mail in error) >please notify the sender immediately and destroy this e-mail. Any >unauthorized copying, disclosure or distribution of the material in this >e-mail is strictly forbidden. > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >
