husted 2002/10/11 14:48:15
Modified: doc/userGuide building_controller.xml
Log:
New 1.1 sections submitted by Eddie Bush.
Revision Changes Path
1.29 +132 -1 jakarta-struts/doc/userGuide/building_controller.xml
Index: building_controller.xml
===================================================================
RCS file: /home/cvs/jakarta-struts/doc/userGuide/building_controller.xml,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- building_controller.xml 10 Oct 2002 03:42:44 -0000 1.28
+++ building_controller.xml 11 Oct 2002 21:48:15 -0000 1.29
@@ -972,6 +972,79 @@
</pre>
</section>
+ <section name="4.7.4.4 Switching Modules" href="module_config-switching">
+ <p>
+ There are two basic methods to switching from one module to another.
+ You can either use a forward (global or local) and specify the
+ contextRelative attribute with a value of true, or you can use
+ the built-in <code>org.apache.struts.actions.SwitchAction</code>.
+ </p>
+ <p>
+ Here's an example of a global forward:
+ </p>
+ <p>
+ <pre>
+ ...
+ <struts-config>
+ ...
+ <global-forwards>
+ <forward name="toModuleB"
+ contextRelative="true"
+ path="/moduleB/index.do"
+ redirect="true"/>
+ ...
+ </global-forwards>
+ ...
+ </struts-config>
+ </pre>
+ </p>
+ <p>
+ You could do the same thing with a local forward declared in an
+ ActionMapping:
+ </p>
+ <p>
+ <pre>
+ ...
+ <struts-config>
+ ...
+ <action-mappings>
+ ...
+ <action ... >
+ <forward name="success"
+ contextRelative="true"
+ path="/moduleB/index.do"
+ redirect="true"/>
+ </action>
+ ...
+ </action-mappingss>
+ ...
+ </struts-config>
+ </pre>
+ </p>
+ <p>
+ Finally, you could use <code>org.apache.struts.actions.SwitchAction
+ </code>, like so:
+ </p>
+ <p>
+ ...
+ <action-mappings>
+ <action path="/toModule"
+ type="org.apache.struts.actions.SwitchAction"/>
+ ...
+ </action-mappingss>
+ ...
+ </p>
+ <p>
+ Now, to change to ModuleB, we would use a URI like this:
+ </p>
+ <p>
+
<code>http://localhost:8080/toModule.do?prefix=moduleB&page=index.do</code>
+ </p>
+ <p>
+ That's all there is to it! Happy module-switching!
+ </p>
+ </section>
+
<section name="4.8 Add Struts Components To Your Application"
href="config_add">
<p>
@@ -985,8 +1058,66 @@
<section name="4.9 Commons Logging Interface" href="logging">
<p>
- [:TODO:]
+ The commons-logging interface is an <i>ultra-thin</i> bridge to
+ many different logging implementations. The intent is to remove
+ compile- and run-time dependencies on any single logging
+ implementation. For more information about the currently-supported
+ implementations, please refer to the
+ <a href="http://jakarta.apache.org/commons/logging/api/index.html";>
+ the description for the org.apache.commons.logging package</a>.
+ </p>
+ <p>
+ Because Struts uses commons-logging and, therefore, includes the
+ necessary JAR files for <b>you</b> to use commons-logging, you've
+ probably had the occassional fleeting thought, <i>"Should I use
+ commons-logging?"</i> The answer (surprise!) depends on the
+ requirements for your particular project. If one of your requirements
+ is the ability to easily change logging implementations with zero
+ impact on your application, then commons-logging is a very good option.
</p>
+ <p>
+ <i>"Great! What do I do to get started using commons-logging in
+ my own code?"</i>
+ </p>
+ <p>
+ Using commons-logging in your own code is very simple - all you need
+ are two imports and a declaration for a logger. Let's take a look:
+ </p>
+ <p>
+ <pre>
+ package com.foo;
+ ...
+ import org.apache.commons.logging.Log;
+ import org.apache.commons.logging.LogFactory;
+ ...
+ public class Foo {
+ ...
+ private static Log log = LogFactory.getLog(Foo.class);
+ ...
+ public void setBar(Bar bar)
+ {
+ if (log.isTraceEnabled())
+ log.trace("Setting bar to " + bar);
+
+ this.bar = bar;
+ }
+ ...
+ }
+ </pre>
+ </p>
+ <p>
+ The general idea is to instantiate a single logger per class and to
+ use a name for the logger which reflects where it's being used. The
+ example is constructed with the class itself. This gives the
+ logger the name of com.foo.Foo. Doing things this way lets you
+ easily see where the output is coming from, so you can quickly
+ pin-point problem areas. In additon, you are able to enable/disable
+ logging in a very fine-grained way.
+ </p>
+ <p>
+ For examples of using logging in Struts classes, see the
+ Action classes in the Struts MailReader example application.
+ </p>
<p>
Next: <a href="building_apps.html">Building Applications</a>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
