PHruts

• Index
• Download
• User Guide
• PHP doc

• 1. Introduction
• 2. Building Model Components
• 3. Building View Components
• 4. Building Controller Components
• 5. Configuring Applications
• Annex

3. Building View Components

3.1 Overview

This chapter focuses on the task of building the View components for use with the PHruts framework. The PHruts distribution includes an API library that provides support for building internationalized applications, as well as for interacting with input forms. Several other topics related to the View components are briefly discussed.

3.2 Internationalized Messages

PHruts includes classes to build internationalized and localized applications. The key concepts to become familiar with are:

• PHRUTS_Locale - The class that supports internationalization. Each PHRUTS_Locale represents a particular choice of country and language (plus an optional language variant).
• PHRUTS_Properties - This class allows you to define resources using the same "name=value" syntax used to initialize properties files. This is very convenient for preparing resource bundles with messages that are used in a web application, because these messages are generally text oriented.
• PHRUTS_MessageResources - The PHruts class phruts::util::PHRUS_MessageResources lets you treat a set of resource bundles like a database, and allows you to request a particular message string for a particular Locale (normally one associated with the current user) instead of for the default Locale the server itself is running in. This class also allows you to replace portions of the message string with arguments specified at run time. This is useful in cases where you are creating a sentence, but the words would appear in a different order in different languages. The placeholder string {0} in the message is replaced by the first runtime argument, {1} is replaced by the second argument, and so on.

Please note that the internationalization (often called "i18n" because 18 is the number of letters in between the "i" and the "n") support in a framework like PHruts is limited to the presentation of internationalized text and images to the user. Support for Locale specific input methods (used with languages such as Japanese, Chinese, and Korean) is left up to the client device, whichis usually a web browser.

Assume that your source code is created in package mycompany::mypackage, so it is stored in a directory (relative to your your application's classes folder) named mycompany/mypackage. To create a resource bundle called mycompany::mypackage::MyResources, you would create the following files in the mycompany/mypackage directory:

• MyResources.properties - Contains the messages in the default language for your server. If your default language is English, you might have an entry like this: prompt.hello=Hello
• MyResources_xx.properties - Contains the same messages in the language whose ISO language code is "xx". For a French version of the message shown above, you would have this entry: prompt.hello=Bonjour. You can have resource bundle files for as many languages as you need.

3.3 Automatic Form Validation

PHruts offers a facility to validate the input fields it has received. To utilize this feature, override the following method in your PHRUTS_ActionForm class:

validate(PHRUTS_ActionConfig $mapping, PHRUTS_HttpServiceRequest $request);

The validate method is called by the controller service after the bean properties have been populated, but before the corresponding action class's execute method is invoked. The validate method has the following options:

• Perform the appropriate validations and find no problems -- Return either null or a zero-length PHRUTS_ActionErrors instance, and the controller service will proceed to call the execute method of the appropriate PHRUTS_Action class.
• Perform the appropriate validations and find problems -- Return a PHRUTS_ActionErrors instance containing PHRUTS_ActionError's, which are classes that contain the error message keys (into the application's PHRUTS_MessageResources bundle) that should be displayed. The controller service will store this array as a request attribute suitable for use by the getErrors API method, and will forward control back to the input form (identified by the input property for this PHRUTS_ActionConfig).

As mentioned earlier, this feature is entirely optional. The default implementation of the validate method returns null, and the controller service will assume that any required validation is done by the action class.

One common approach is to perform simple, prima facia validations using the ActionForm validate method, and then handle the "business logic" validation from the Action.

Previous: Building Model Components

Next: 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.