Before you can build an application, you need to lay a solid foundation. There are several setup tasks you need to perform before deploying your PHruts application. These include components in the PHruts configuration file and in the Web Application Deployment Descriptor.
The Building Controller Components chapter covered writing the form-bean and action-mapping portions of the PHruts configuration file. These elements usually play an important role in the development of a PHruts application. The other elements in PHruts configuration file tend to be static: you set them once and leave them alone.
These "static" configuration elements are:
The <controller> element allows you to configure the ActionService.
This example uses the default values for several controller parameters. If you only want default behavior you can omit the controller section altogether.
<controller processorClass="phruts::action::PHRUTS_RequestProcessor
contentType="text/html"/>;
PHruts has built in support for internationalization (I18N). You can define one or more <message-resources> elements for your webapp; modules can define their own resource bundles. Different bundles can be used simultaneously in your application, the "key" attribute is used to specify the desired bundle.
Example configuration:
<message-resources parameter="MyWebAppResources"
null="false"/>
This would set up a message resource bundle provided in the file MyWebAppResources.properties under the default key. Missing resource keys would be displayed as "???keyname???".
PHruts PlugIns are configured using the <plug-in> element within the PHruts configuration file. This element has only one valid attribute, "className", which is the fully qualified name of the PHP class which implements the phruts::action::PHRUTS_PlugIn interface.
For PlugIns that require configuration themselves, the nested <set-property> element is available.
This is an example using the Smarty plugin:
<plug-in className="phruts::plugins::PHRUTS_Smarty">
<set-property property="template_dir"
value="/WEB-INF/smarty/templates"/>
<set-property property="compile_dir"
value="/WEB-INF/smarty/templates_c"/>
</plug-in>
Very little is required in order to start taking advantage of the Struts application module feature. Just go through the following steps:
In PHruts, you have two options: you can list multiple phruts-config files as a comma-delimited list, or you can subdivide a larger application into modules.
With the advent of modules, a given module has its own configuration file. This means each team (each module would presumably be developed by a single team) has their own configuration file, and there should be a lot less contention when trying to modify it.
In order to tell the PHruts machinery about your different modules, you specify multiple config initialization parameters, with a slight twist. You'll still use "config" to tell the action service about your "default" module, however, for each additional module, you will list an initialization parameter named "config/module", where module is the name of your module (this gets used when determining which URIs fall under a given module, so choose something meaningful!). For example:
...
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/conf/phruts-default.xml</param-value>
</init-param>
<init-param>
<param-name>config/module1</param-name>
<param-value>/WEB-INF/conf/phruts-module1.xml</param-value>
</init-param>
...
This says I have two modules. One happens to be the "default" module, which has no "/module" in it's name, and one named "module1" (config/module1). I've told the controller it can find their respective configurations under /WEB-INF/conf (which is where I put all my configuration files). Pretty simple!
(My phruts-default.xml would be equivalent to what most folks call phruts-config.xml. I just like the symmetry of having all my PHruts module files being named phruts-<module>.xml)
Here's an example of switching from one module to another in a global forward:
...
<phruts-config>
...
<global-forwards>
<forward name="toModuleB"
path="/index.php?do=/moduleB/action1"
redirect="true"/>
...
</global-forwards>
...
</phruts-config>
You could do the same thing with a local forward declared in an ActionConfig:
...
<phruts-config>
...
<action-mappings>
...
<action ... >
<forward name="success"
path="/index.php?do=/moduleB/action1"
redirect="true"/>
</action>
...
</action-mappings>
...
</phruts-config>
To change to ModuleB, we would use a URI like this:
http://localhost:80/myApp/index.php?do=/moduleB/action1
You can switch back to the "default" module with a URI like this:
http://localhost:80/myApp/index.php?do=/action1
The final step in setting up the application is to configure the application deployment descriptor (stored in file WEB-INF/web.xml).
Add an entry defining the action service itself, along with the appropriate initialization parameters. Such an entry might look like this:
<service pathParam="do">
<include-paths>
<include-path path="/WEB-INF/lib/pear"
context-relative="true"/>
</include-paths>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/phruts-config.xml</param-value>
</init-param>
</service>
Previous: Building Controller Components
This documentation is a modified copy of the Apache Struts 1.1 framework user guide, and so is copyrighted under the ASF license.