<xsl:variable name = "x">
<xsl:call-template name = "test">
<xsl:with-param name="a" select="."/>
</xsl:call-template>
</xsl:variable>
In this example the result produced by <xsl:call-template> is likely to be a single Text node. But it can also be a DOM tree. This kind of RTF cannot be modelled by SimpleResultTreeImpl.
AdaptiveResultTreeImpl can be considered as a smart switcher between SimpleResultTreeImpl and SAXImpl. It treats the RTF as simple Text and uses the SimpleResultTreeImpl model at the beginning. However, if it receives a call which indicates that this is a DOM tree (e.g. startElement), it will automatically transform itself into a wrapper around a SAXImpl. In this way we can have a light-weight model when the result only contains simple text, while at the same time it still works when the RTF is a DOM tree.
All methods in this class are overridden to delegate the action to the wrapped SAXImpl object if it is non-null, or delegate the action to the SimpleResultTreeImpl if there is no wrapped SAXImpl.
%REVISIT% Can we combine this class with SimpleResultTreeImpl? I think it is possible, but it will make SimpleResultTreeImpl more expensive. I will use two separate classes at this time.
| Modifier and Type | Field and Description |
|---|---|
| private final AttributesImpl | |
| private boolean | |
| private static int | |
| private SAXImpl | |
| private int | |
| private String | |
| private DTMWSFilter | _wsfilter
The following fields are only used for the nested SAXImpl |
| private static final String |
| Access | Constructor and Description |
|---|---|
| public | AdaptiveResultTreeImpl(XSLTCDTMManager dtmManager, int documentID, DTMWSFilter wsfilter, int initSize, boolean buildIdIndex)
|