[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
On 18/11/2012 18:42, Andrew Welch wrote:
The only minor niggle is with embedded bracketed substructures '(...)' where the numbering to access them, regex-group(n), depends upon the position in the composite sequence.
Re: [xsl] analyze-string gotcha/reminder
Subject: Re: [xsl] analyze-string gotcha/reminder From: John Lumley <John.Lumley@xxxxxxxxxxxxxx> Date: Tue, 20 Nov 2012 13:35:41 +0000 |
On 18/11/2012 18:42, Andrew Welch wrote:
A useful technique I've found with a multi-case xsl:analyze-string is to use a set of variables for each of the regex alternatives and then join them for a composite alternative expression, viz:Yep, or the usual way is to put the regex in the content of a variable with as="xs:string":
<xsl:variable name="regex" as="xs:string"> no need to worry about anything here </xsl:variable>
<xsl:variable name="r1">\d+</xsl:variable> <xsl:variable name="r2">[A-Za-z]+</xsl:variable> .... <xsl:analyse-string select="." regex="{string-join(($r1,$r2),'|')}"> <xsl:matching-substring> <xsl:choose> <xsl:when test="matches(.,$r1)">It's a number</xsl:when> <xsl:when test="matches(.,$r2)">A word this time....</xsl:when> ....... This has three advantages: i) you only define each case once, ii) dealing with entities such as quotes is much easier and iii) it's much clearer what the alternatives are.
The only minor niggle is with embedded bracketed substructures '(...)' where the numbering to access them, regex-group(n), depends upon the position in the composite sequence.
-- John Lumley MA PhD CEng FIEE john@xxxxxxxxxxxxxx
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] analyze-string gotcha/rem, Andrew Welch | Thread | Re: [xsl] analyze-string gotcha/rem, Ihe Onwuka |
Re: [xsl] Basic template matching i, Ruud Grosmann | Date | RE: [xsl] Basic template matching i, An OldBloke |
Month |