Ok, I understand how forcing all requests through the controller is a good
thing.  Now, I have various types of pages:

Forms - <html:form...
Actions - .do action of the form
View - basic .jsp page to view and link to a form for further edit

Is there a naming convention that you found works for you?  Since, I am
using .do extension for everything, it seems like I have URL's which look
like this:

AddressForm.do
AddressSaveAction.do
AddressView.do

I think it would be nice to have:

Address.form
AddressSave.action
Address.view

Or something like this.  The .do extension makes me think of "action" and I
don't see a form or a view as an action.  I could always map *.view and
*.form to execute the servlet as well, but then Address.form and
Address.view are ambiguous.

Any suggestion on naming conventions?

Thanks.
-AP_
http://www.alexparansky.com


-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 3:47 PM
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method


In 1.0.x, it is often suggested that each link at least be represented
by an ActionForward. This centralizes control over the hyperlinks in the
Struts Config, which yields a number of benefits.

In Struts 1.1, now the Nightly Build, support has been added for
multiple Struts configuration files. In order for this feature to work,
any request for a presentation page that uses elements from the
configuration file (ActionForms, forwards, mappings) must be routed
through the controller. This allows the controller to make the
appropriate configuration available for a given page.

This is becoming a common pattern, since the Velocity support, and I
believe the X2 servlet, also need you to do the same thing for the same
reason. The controller needs to touch the request to prepare it for the
presentation layer.

Many other features in advanced applications, including security,
logging, and screen definitins, are easier to implement when everything
passes through the controller.

In a strict MVC implementation, the controller is responsible for
interacting with the user. It then follows that all requests from the
user should flow through the controller. Some of us had been counting
the ActionForwards as flowing through the controller, but as the
framework expands, and more services are being plugged in, passing the
actual request through the controller becomes more and more desirable,
until it's really not worth making the occasional exception any more.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Alex Paransky wrote:
>
> So do you mean, all pages go through the Action?  Even those which are not
> forms and for display purposes only?  Could you shed some light as to why
> this is preferred?
>
> Thanks.
>
> -AP_
> http://www.alexparansky.com
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 2:02 PM
> To: Struts Users Mailing List
> Subject: Re: Design question about ActionForm's validate method
>
> 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]>
>
> --
> 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]>

Reply via email to