Summary, and a Few Odds and Ends
One issue not covered in the Controller Design discussion is that of input validation.
Validation requirements are limited to the need to verify valid formats of mail addresses entered on the Address Book page, or typed directly on the Compose page. The Struts Validator is an obvious candidate to implement this, but integrating it into the design cannot be considered independently of the decision to amalgamate related actions into dispatch-style Action classes. These actions include those which cause the initial transition from one page to another, triggered by selection of a link in the menu pane. In this circumstance, fields which would be subject to validation are properly blank when the page in question is first entered. So although a non-blank email address is required when the user attempts to send a message after composition, a blank address is valid upon entry into the Compose page.
However, configuration of validation rules is at the granularity of the Action object, rather than individual methods within it. Since the validation requirements are minimal, analysis of the tradeoffs, in the context of the overall design, tipped the balance in favour of the dispatch-style Actions. The ComposeAction.send method uses the EmailValidator class directly, and the errors made available to the view via the standard ActionErrors feature.
This concludes my discussion of the project. I may in the future release the source code under public licence. First, I want to consider a few enhancements, such as:
- An administration application to centralize configuration of mail servers and user accounts, including user specific mail server settings
- Replace the HTML form Submit buttons with links, allowing larger fonts than those of standard form buttons, providing for ease of use by folks with weak vision.