Subject: Re: [xsl] best practices for using XSLT modes From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 4 Dec 2019 10:43:55 -0000 |
> That example seems to be too simple or artificial to show the value of > modes. In general I think modes have their value if you need to process > the same type of nodes twice e.g. once for generating a table of > contents and the second time for splitting into result documents. Or, in > the context of XSLT 3, if you need to separate processing steps working > with streamed input nodes from ones using grounded ones. > Modes are also useful if you have to process multiple documents with different vocabularies; it helps to modularise the logic, and in particular, for someone reading the code, if apply-templates uses a specific mode then it reduces the effort needed to find the template rules that might get invoked -- which is a significant part of the effort of debugging stylesheets. I'm certainly inclined to keep modes small where possible. But clearly if a mode has only one rule, then you wonder why xsl:apply-templates is being used at all; and if it only has two or three rules, then you wonder whether a conditional (e.g. xsl:choose) might not be more appropriate. An interesting recent experience: we have a test driver for running XSLT tests, that's written in XSLT. The test assertions might take the form: <result> <assert>/res = 'Success'</assert> </result> or <result> <any-of> <assert>/res = 'Success'</assert> <error code="XTSE0020"/> </any-of> </result> Now, firstly, we use a mode for evaluating assertions, that's separate from the mode used for processing other things in the test catalog. A good reason for that is that all the template rules in that mode return a boolean (indicating test success of failure), and the apply-templates call has to know that a boolean result is expected. The rules in a mode have to have equivalent pre- and post- conditions in terms of things like the expected parameters and the required return type, because they are interchangeable as far as the caller is concerned. Secondly, I found it useful recently to split the mode for evaluating assertions into two: one mode handles the case where the test produces a normal result, the other handles the case where it produces a dynamic error, and we issue a different apply-templates instruction for the two cases. The reason for this is that the two modes have different default behaviour (the mode that handles error outcomes returns "false" for all assertions except the one with match="error"): this change eliminated a lot of logic. Perhaps the same effect could have been achieved using a generic template rule delegating to specific template rules using next-match; but in this scenario where we're basically handling a two-dimensional decision tree (X - what is the outcome of a test?, Y - what is the assertion being tested?) then using modes for one of the dimensions and match patterns for the other can be useful. I would find it quite difficult to capture this experience and produce general guidance on XSLT coding/design patterns; but if you're writing complex stylesheets, modes are a powerful tool at your disposal and can be used with care to great effect. Michael Kay
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] best practices for using , Mukul Gandhi gandhi. | Thread | Re: [xsl] best practices for using , Mukul Gandhi gandhi. |
Re: [xsl] best practices for using , Mukul Gandhi gandhi. | Date | Re: [xsl] best practices for using , Dimitre Novatchev dn |
Month |