To a certain degree, we recommend sectioning the Java Serve Pages so that often used fragments can be separated into individual, reusable JSP files that can be included with <dsp:include>. While this sectioning makes site development and maintenance easier, it also can make the site perform poorly if overused. However, you don’t have to sacrifice all modularity in your Java Server Pages for better performance.
Each droplet invocation, either by <dsp:include page="filename.jsp" flush="true"/> or <dsp:droplet name="/atg/dynamo/droplet/BeanName">, is compiled into a SubServlet invocation.
Another option for sectioning Java Server Pages is using JSP include directives, which work similarly to droplet src. The syntax is as follows:
<dsp:include file="RelativeURLSpec.jsp">
This directive includes the JSP fragment at RelativeURLSpecJSP to be “in-lined” in the JSP in which this line is written. The in-lining occurs before page compilation and the two files are treated as one fragment rather than as the two fragment invocations you would get using the <dsp:inclide="RelativeURLSpec.jsp"></dsp:include> syntax.
The use of the IsEmpty and IsNull components gives the developer security from NullPointerExceptions but invoking each of these servlet beans takes time. To avoid this problem you can eliminate excess IsNull invocations when you know that a value really can or cannot be null. For example, while iterating over a list of SKUs for a product with a ForEach and displaying some properties for each SKU, it is a good idea to perform an IsNull check on each of them. However, there are situations where you can be virtually certain that none of the SKUs will be null. One of these situations is when each SKU on the list is retrieved as a product.childSKU. If your database is in good shape and if you test to ensure that the list has no nulls in it, you can be virtually assured that it never will have nulls. In cases like this, you can comfortably eliminate the IsNull check to improve performance.
The following code sample is an example in which you would likely use ForEach to iterate over an array. If you assume that it is possible, but not very likely, that the array has no elements, it is best to invoke ForEach without checking ahead of time if the array is empty. Instead, use the <dsp:oparam name="empty"> of ForEach as shown here:
The contents of someArray: <P> <dsp:droplet name="ForEach"> <dsp:param name="array" param="param:someArray"/> <dsp:oparam name="empty"> <i>someArray has no elements!</i> </dsp:oparam> <dsp:oparam name="outputStart"> </OL> </dsp:oparam> <dsp:oparam name="outputEnd"> </OL> </dsp:oparam> <dsp:oparam name="output"> <LI><dsp:valueof param="element"></dsp:valueof> </dsp:oparam> </dsp:droplet>
If you assume that most of the time the array is empty and only sometimes has elements, it may be more efficient to check if the array is empty before invoking ForEach, as in this example:
The contents of someArray: <P> <dsp:droplet name="IsEmpty"> <dsp:param name="value" param="param:someArray"/> <dsp:oparam name="empty"> <i>someArray has no elements!</i> </dsp:oparam> <dsp:oparam name="false"> <OL> <dsp:droplet name="ForEach"> <dsp:param name="array" param="param:someArray"/> <dsp:oparam name="output"> <LI><dsp:valueof param="element"></dsp:valueof> </dsp:oparam> </dsp:droplet> </OL> </dsp:oparam> </dsp:droplet>
The efficiency gained here is the difference between the time it takes to invoke ForEach, to figure out what kind of object someArray is, and to inquire if it is empty versus the time is takes to invoke IsEmpty, which goes through roughly the same calculations. For both situations, the former code snippet performs approximately as well or better than the latter.
