Re: [xsl] Legibility, repetition, nesting

["David Birnbaum djbpitt@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

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 <>)