Phrame 3 supports a large part of the Struts functionality up till Struts version 1.2. Current functionality includes:
- Support for multiple configuration files. This enables you to split up your web application into application modules to improve maintainability;
- Introduction of wrapper objects for a request received from the client, the session matching this request and the response to be returned to the client (
HttpRequest, HttpSession and HttpResponse respectively);
- Full fledged
Action and ActionForm classes and extensions as supported by Struts, for example: DispatchAction and DynaActionForm (latter not supported by Phrame 3.0.1);
ActionMessages and ActionErrors classes supported by a MessageResources class with parameterized and localized messages;
- Capability to load predefined function libraries for use in your views (web pages) as a (poor) equivalent for Java tag libraries. A PhrameTagLib is included giving access to a range of predefined variables, e.g.
$_APPLICATION, $_HTTP_REQUEST and $_ERRORS.
Phrame's Struts coverage is still extending. See the feature requests for already planned extensions.
Phrame 3 also supports some of the functionality that is normally provided by a Java Web Container and / or defined in a Web Application Deployment Descriptor. This includes:
- User session validation, meaning the action server will automatically time out a user's session after a given period of time;
- Customisable error pages for certain action server errors, such as a session time out or access denied error;
- Language negotiation with respect to your application's views (web pages), much similar to Apache's content negotiation mechanism for increased i18n support;
- Customisable welcome page, which is shown if a request does not refer to an application module, nor to an action;
- Support for multiple action servers in one container configuration, which can be selected dynamically.
Phrame 3 (as its predecessor Phrame 2) uses a lightweight mechanism to configure the action server and the application modules of your web application. By default, configurations are represented in arrays rather than XML, which you can define directly in your configuration files. In addition module configurations are cached once they have been parsed.
Since configuration data typically has to be parsed each time an action server is started, this reduces parsing overhead to a minimum. You can however still define your module configurations in XML and use the XMLConfigDigester to parse them into the internal Phrame Mapping Array. (Note: this is not yet supported)
To reduce the start up time of an action server even further, Phrame uses a
just in time mechanism to load class definitions and message resources. When the action server fires up, only the Phrame core classes and the message resources used internally by Phrame are loaded.
All other classes, such as your custom made Actions and ActionForms, as well as all your application defined message resources are loaded only when needed. In addition message resources are cached to speed up repeated use of messages.