The best practice now is to use ActionMappings for everything, so that
the reqeust passes through the controller.
This buys you several important capabilities that become important as
applications grow. Not the least of which is the new support for
multiple applications in the Nightly Build.
The ActionMapping has a validate property that you can use to turn off
validation when the mapping is used to initialize a new form. So,
typically, you will have an ActionMapping for each circumstance.
<action
path="/item/Add"
type="org.apache.struts.actions.ForwardAction"
parameter="/pages/item/Form.jsp">
name="itemForm"
scope="request"
validate="false">
</action>
<action
path="/item/Store"
type="org.apache.gavel.item.http.Store"
name="itemForm"
scope="request"
validate="true"
input="/pages/item/Form.jsp"">
<forward
name="continue"
path="/do/donor/Detail"/>
</action>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
Sid Stuart wrote:
>
> 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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
