Subject: Re: [xsl] Legibility, repetition, nesting From: "David Birnbaum djbpitt@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 20 Jul 2020 20:18:37 -0000 |
Dear Andre (cc xsl-list), Thank you for the quick response. This is appealing because it reduces the repetition of <xsl:param> inside the secondary templates, since I would pass just one item, instead of five separate variables. Best, David On Mon, Jul 20, 2020 at 4:00 PM Andre Cusson akhu01@xxxxxxxxx < xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > 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) >> > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3318727> (by > email <>)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Legibility, repetition, n, Andre Cusson akhu01@ | Thread | Re: [xsl] Legibility, repetition, n, Wendell Piez wapiez@ |
Re: [xsl] Legibility, repetition, n, Andre Cusson akhu01@ | Date | Re: [xsl] How to store a sequence i, Wendell Piez wapiez@ |
Month |