2.13 Inline Lists
Rationale
Weblet XSL templates are heavily parameterized in order to give the WAM developer the ability to customize the results.
For example, the std_anchor weblet has the ability to change its appearance when the mouse hovers over it. To activate this behavior, the developer assigns a value to the property. The following XSLT is executed at runtime to see if the property has been set and, if so, adds onmouseover/onmouseout event handlers to the anchor:
<xsl:if test="$mouseover_class != ''">
<xsl:attribute name="onmouseover">
<xsl:text>this.className='</xsl:text>
<xsl:value-of select="$mouseover_class" />
<xsl:text>'</xsl:text>
</xsl:attribute>
<xsl:attribute name="onmouseout">
<xsl:text>this.className='</xsl:text>
<xsl:value-of select="$class" />
<xsl:text>'</xsl:text>
</xsl:attribute>
</xsl:if>
Once the WEBROUTINE design has been saved, the value of never changes but this code is still executed every time the webroutine is run. If the weblet is in a list, the code is executed again for every row of the list.
Now, in most cases, many of the parameters (weblet properties) are constant and don't depend on runtime values. It is more efficient to apply these properties once at design time instead of doing it every time at runtime. This is particularly important in the case of lists (even more so for large lists).
This is what inline lists do. Inline lists differ from standard lists in that the XSL is done at design time. All weblet properties that can be applied at design time are resolved, and special extension elements and functions are used to allow WAMs to use runtime values where needed.
Applying the XSL during design time means that you can't customize an inline list with information (such as field values) that is only available at runtime. This is a trade-off. If you need this extra flexibility you use a standard list. If you don't need it you can benefit from the better performance provided by an inline list.