Subject: Re: [xsl] Legibility, repetition, nesting From: "Andre Cusson akhu01@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 20 Jul 2020 20:00:53 -0000 |
Hi, Why not put the variables in a structure (ex. markup, map, array), the apply-templates with type selector and pass the parameter structure, possibly through a tunnel param with an additional dispatch template? Regards, ac Le lun. 20 juil. 2020 C 14:23, David Birnbaum djbpitt@xxxxxxxxx < xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> a C)crit : > Dear Syd (cc xsl-list), > > Thanks for the quick response. As you note, the actual main template does > a lot of things that are common to all types before it gets to the > <xsl:choose>, and if I write completely separate templates for each of the > types, I would need to repeat that shared code verbatim in each of the > type-specific templates. The variables do have to be inside the templates > because they are specific to each item. It isn't just variables, there are > about 30 lines of code common to all items, including variable > declarations, literal result elements (depending on variables), copies of > elements and attributes. and a couple of for-each statements, with the > <xsl:choose> inside the inner for-each. > > Best, > > David > > > > On Mon, Jul 20, 2020 at 1:32 PM Bauman, Syd s.bauman@xxxxxxxxxxxxxxxx < > xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > >> Hi David! >> >> I donbt feel qualified to pontificate on *best* practice, but happy to >> suggest pros and cons of alternatives. But first, letbs make sure I have >> this rightbthe current basic structure is roughly as follows: >> >> <xsl:template match="item"> >> <xsl:variable name="pre-choose-var-1" select="''"/> >> <xsl:variable name="pre-choose-var-2" select="''"/> >> <xsl:copy> >> <xsl:sequence select="common-stuff"/> >> <xsl:choose> >> <xsl:when test="@type eq '001'"><!-- 001-specific --></xsl:when> >> <xsl:when test="@type eq '002'"><!-- 002-specific --></xsl:when> >> <!-- ... --> >> <xsl:when test="@type eq '133'"><!-- 133-specific --></xsl:when> >> <xsl:when test="@type eq '134'"><!-- 134-specific --></xsl:when> >> </xsl:choose> >> </xsl:copy> >> </xsl:template> >> >> If so, I wonder if dividing the one huge template up into 134 small ones >> would be more manageable: >> >> <xsl:template match="item[@type eq '001']"> >> <xsl:variable name="pre-choose-var-1" select="''"/> >> <xsl:variable name="pre-choose-var-2" select="''"/> >> <xsl:copy> >> <xsl:call-template name="do-common-stuff"/> >> <!-- 001-specific --> >> </xsl:copy> >> </xsl:template> >> >> No bmainb template at all. If the pre-choose variables do not depend on >> @type, a lot of repetition, though. (I am presuming the variables need to >> be inside the template, which you implied, but did not state, if I read >> right.) >> >> Just a thought. Stay safe, keep coding. >> >> ------------------------------ >> >> I write here for advice about Best Practice. The question is at the end; >> because I am constitutionally unable to be concise, the long narrative >> before it is context. >> >> I'm developing an XSLT stylesheet that processes 134 different types of >> items (same generic identifier, distinguished by an attribute value). For >> each item, regardless of type, I create several variables, do an >> <xsl:copy>, and inside that first create some other content that is common >> to all items, regardless of type, and then use <xsl:choose> to handle the >> types differently, according to their idiosyncrasies. I began by >> implementing this as a single template with a long <xsl:choose> deeply >> nested inside it, which has the advantage of avoiding unnecessary >> repetition, since the shared operations are outside the <xsl:choose>. It >> works, but perfectionism is a terrible curse ... >> >> Perhaps I'm being arbitrarily fastidious, but the <xsl:choose> inside the >> deep nesting feels awkward; I wind up with one template that runs to more >> than a thousand lines, where the <xsl:choose> is seven levels deep. This >> made me wonder whether off-loading the type-specific tasks to separate >> templates or functions, which could be called from the appropriate place, >> would keep the main template down to a more manageable size. Specifically, >> I'd like to be able to put the code blocks currently inside of the >> <xsl:when> statements somewhere other than deep inside a single main >> template. >> >> One implementation of this approach that works, but comes with its own >> issues, is using an <xsl:next-match> with auxiliary lower-priority >> templates that match item[@type eq 'x']. This lets me break out the >> type-specific code into separate templates. The reason this is not wholly >> satisfactory is that I have to pass all of the variables into these >> separate templates as parameters, so I wind up repeating the same >> <xsl:param> statements inside each of the secondary templates. That much >> repetition feels suboptimal. >> >> The only approach that occurs to me that might simultaneously eliminate >> repetition and avoid putting all of the processing inside a single >> thousand-line template, most of which is the <xsl:choose> with all of the >> type-specific handling inside <xsl:when> children, is to put the >> type-specific processing into separate files, with an <xsl:when> root, and >> then <xsl:include> them inside the <xsl:choose>. One downside seems to be >> that they will not be valid XSLT (they wonbt have the necessary wrapper >> boilerplate and the variables they use wonbt be defined inside them), which >> I think I could overcome by using an <oXygen/> "master document", which >> would cause them to be validated in context. That isn't ideal, since it's >> tied to a specific development environment, but since that happens to be my >> usual development environment, the objection is philosophical (= can be >> ignored in the interest of Getting The Job Done), rather than practical. >> >> So: Is there a Best Practice approach to breaking out the type-specific >> treatment of the different types of items that avoids both 1) unnecessary >> repetition and 2) embedding a single thousand-line <xsl:choose>, which >> contains all of the type-specific operations, seven levels deep inside a >> template? >> >> >> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> >> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3318727> (by >> email) >> > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3035779> (by > email <>)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Legibility, repetition, n, David Birnbaum djbpi | Thread | Re: [xsl] Legibility, repetition, n, David Birnbaum djbpi |
Re: [xsl] Legibility, repetition, n, David Birnbaum djbpi | Date | Re: [xsl] Legibility, repetition, n, David Birnbaum djbpi |
Month |