ATG Form Handler 最佳实践

项目开发过程过半，其中对ATG的Form Handler应用不少，虽然初识Form Handler时，觉的其实跟Struts的Action颇为类似，但是一个多月用下来，感觉还是有点区别的。

搜索得到一篇Form Handler的最佳实践的总结，看下来，醍醐灌顶，如下：

来自谷歌论坛：

These guidelines lay out some suggestions, strategies, and direction for making the best use of form handlers with ATG. The intent here is to provide developers with some insights and structural suggestions distilled from the long hours of many people hunched over their monitors and keyboards. The goal is simple – to provide guidelines that will lead to leaner, easier to debug, and easier to extend implementations of ATG user interfaces. Since form handlers act as the focal point for all user supplied data entering the system from the open Internet, their effective structuring is key to the overall long term health of the system.

General Guidelines

Each and every form should have an associated form handler. This doesn’t necessarily imply a custom form handler – these could be an instance of the ProfileFormHandler or even the RepositoryFormHandler.

Custom form handlers should be 1:1 with custom forms. Don’t attempt to reuse form handlers across multiple forms. Keep it simple.

Form handlers may be either request or session scoped, with strong preference given to request scope. In general, if the form is used very frequently it may be session scoped so as to avoid instantiating new copies. However, when session scoping is used then tighter maintenance of instance variables must accompany that (and session scoping form handlers is the exception).

Session scoping of form handlers should never be used to achieve session persistence … that’s what manager components are for.

Form handlers should only reference components that are scoped at the same or more general scoping as themselves (for example session->session, session->global). Don’t use the nucleus resolveName(String componentName) method to avoid fixing bad scoping decisions; this method is extremely expensive and should only be used when it can’t be avoided (which is generally when a pipeline component needs access to session data).

Form handlers should never reference properties or call methods in other form handlers. If multiple form handlers share some information, that information is generally persisted for the session and should be managed out of a common, shared manager component.

The function of the form handler is to:
intercept and cause form field values to be validated prior to a handle method calling the pertinent action method in the manager component.

provide information for form widgets such as selection lists, radio buttons, etc.

provide structured data on demand (ex. json or xml for Ajax widgets)

provide feedback to the JSP so that field errors can be reflected by to the consumer in such a way as to assist them with fixing the errors easily

supply data to manager components

exercise methods in validator components that ensure that the field values supplied by the user are consistent with business guidelines and needs

exercise methods in manager components that persist data and/or exercise system function in response to action requests

All validation business logic should be contained in a validator component that is called from a handle method in the form handler.

Form handlers should contain no business logic. Even the validation of form field values should be externalized in either a manager component or a validator component as best befits the application.

All user supplied data values should be accepted via form fields. Don’t use droplets, nucleus components, or web services as a “short cut” to forms. The reason that these can sometimes be easier is that they bypass things like field security, cross system scripting defenses, automatic encoding and decoding, validation layers, before and after set logic, etc. Yes, they are faster. In the same way that the fastest way to get from the overlook to the bottom of the Grand Canyon is to jump off of the rim. The jumping is easy … it’s the landing that brings the pain.

Implementation Details Requiring Consistency

Return false at the end of the handle methods if you want to stop the form submission request (which will be for the “action” attribute of the form) from being processed. Return true to redirect to a success page.

Avoid setting the successURL, errorURL, and other pages used for redirection in the JSP/form. Instead set them in the form handler’s properties file. Having them in the form exposes the site to cross-site scripting [XSS] attacks.

When binding input fields that are not submit buttons or images, make sure to set the priority of the field to “-10” so that it gets invoked after all of the setters have been called.