[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] analyze-string gotcha/reminder
Subject: Re: [xsl] analyze-string gotcha/reminder From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx> Date: Wed, 21 Nov 2012 01:40:32 +0000 |
On Tue, Nov 20, 2012 at 1:35 PM, John Lumley <John.Lumley@xxxxxxxxxxxxxx> wrote: > On 18/11/2012 18:42, Andrew Welch wrote: >> >> 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> > > 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: > > <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. > hmmm but if the Gods had meant us to do this would they have invented flag="x"?
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] analyze-string gotcha/rem, John Lumley | Thread | Re: [xsl] analyze-string gotcha/rem, John Lumley |
RE: [xsl] Basic template matching i, Liam R E Quin | Date | Re: [xsl] analyze-string gotcha/rem, Ihe Onwuka |
Month |