Hi,
live and learn eh! I revise my recommendation, you still need two URL's, but they
can go to defined action paths.
However, beware of users browsing directly to the JSP's and code with that in mind.
Also to stop yourself going mad, make sure the GET path and POST path are different
eg GET
/jsp/apageGet
POST
/jsp/apagePost.do
Jonathan
ps now rewritting my code gen.
---------------------------------------- Message History
----------------------------------------
From: "Robert Scaduto" <[EMAIL PROTECTED]> on 05/02/2002 13:31 EST
Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
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]>
--
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]>
