struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Struts Controller
Date Sun, 02 Feb 2003 07:26:19 GMT


On Sun, 2 Feb 2003, Alireza Fattahi wrote:

> Date: Sun, 2 Feb 2003 09:58:07 +0330
> From: Alireza Fattahi <Alireza.Fattahi@pdpsoft.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: 'Struts Users Mailing List' <struts-user@jakarta.apache.org>
> Subject: Struts Controller
>
> Hi,
>
>
> I have read some information about <controller> tag which is used in
> strusts_config.xml but I did not get the idea. WHERE this controller could
> be usefull?
>

The <controller> element in struts-config.xml does not define an object
per se.  Instead, it defines a set of configuration parameters that modify
how the org.apache.struts.action.RequestProcessor class will perform its
work.  For example, if you do *not* want the RequestProcessor to
automatically create a Locale object (from the user's browser
configuration for language preference), and store it in the session, you
would say:

  <controller ... locale="false" .../>

in your struts-config.xml file.  By default, Struts does this for you
(because most people want it), but it's your option to turn the feature
off if you don't need it.

In Struts 1.0.2, everything in the <controller> element was set via
initialization parameters to the controller servlet itself.  That does not
work for Struts 1.1, because you can have different settings for different
application modules.  Thus, we had to move the settings into the
struts-config.xml file instead.

> What I have read is: from theserverside.com
> The <controller> element is new to version 1.1. Prior to version 1.1, the
> ActionServlet contained the controller functionality and you had to extend
> that class to override the functionality. In version 1.1 however, Struts has
> moved most of the controller functionality to the new RequestProcessor
> class. The ActionServlet still receives the requests, but then delegates the
> request handling to an instance of the RequestProcessor class that has been
> installed. This allows you to declaratively assign the processor class and
> modify its functionality.
>

You can, in fact, have your own separate RequestProcessor subclass per
application module, if you want.  However, the most common use for the
<controller> element is to configure things like "create a Locale object
automatically" on a per-module basis, instead of having to make one global
decision for all modules.

> Alireza.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message