Sometimes a site requires functionality that cannot be achieved from the servlet beans already included in ATG, so as a developer you can write your own. To achieve desired performance, you should first ensure that the servlet bean itself does its job efficiently; then, minimize the need for “helper” droplets.
For example, some servlet beans fail if given a null value in an input parameter. Make your servlet bean accept null input parameters. If it takes input parameters, do the quick comparison to null or empty inside the service method rather than using the Java Server Page to invoke IsNull or IsEmpty on the parameter value before invoking your servlet bean.
Another example is if your servlet bean outputs an array that is then iterated by ForEach. This common pattern works well because it is usually efficient and it is easily maintainable and readable by people who have used ForEach before. However, if ForEach then requires a Switch servlet bean on each element and in some cases invokes another servlet bean and so on and so on, there may be a point where it is better to do the iteration within your own servlet bean.
To summarize, we do not recommend creating a whole site of customized servlet beans to gain performance. Nor do we recommend that site developers begin by thinking about where they can and cannot use Cache and how much code they can write inline. Instead, we recommend that site development begin with modular JSP fragments used sensibly in an overall site structure driven by functionality and design. When your site is somewhat functional, you should begin testing to see if it meets your performance goals and needs. If it does not, then you should identify the slowest and most often used parts of the site and improve their performance.
