Re: [xsl] having a template remember not to call itself again

["Joel Kalvesmaki director@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

When I've reached such quandaries in the past, every time, without 
exception, I eventually learn that I had been 
overthinking/overengineering the problem. Some time off from the project 
helps me find a simpler, more elegant approach. Sometimes I replicate 
the problem on paper or with playing cards. Self-observation on how I do 
the task manually helps me simplify the code.

One principle I've personally adopted is to ban intentional template 
recursion. I put any recursion into functions (or an xsl:iterate 
structure). A function can provide stronger encapsulation than a 
template mode, and provides certain opportunities to diagnose problems.

A second principle I follow is to have templates call each other in a 
linear sequence (or, if you will, a directed acyclic graph), and to give 
them names that reminds me of the order within the sequence. If template 
mode step six has to call mode step one, I almost always know there is 
something wrong in my design. Something should be done in step 1, or 
before it, to avoid such a need.

In a code library I maintain, I have an exception where two template 
modes interact with each other, and I regret that I have not found an 
adequate replacement, because it is one of the hardest things for me to 
diagnose and debug. And I don't fully understand what I've made.

jk

On 2023-03-05 09:20, Chris Papademetrious 
christopher.papademetrious@xxxxxxxxxxxx wrote:
> Hi everyone,
>
> When a template applies its processing first then calls other
> templates last, I will call it "tail-call" template chaining (although
> I don't know the correct term).
>
> For "tail-call" chaining to work, PROCESSING1_HERE must transform the
> content so that CONDITION1_HERE is not met again (or at least not met
> in a way that loops infinitely).
>
> But, what if PROCESSING1_HERE is very complex (nested moded templates,
> recursion, etc.) and sometimes CONDITION1_HERE will match after this
> template was previously applied, and there is no practical way to
> embed the complexity of predetermining PROCESSING1_HERE's failure to
> remove the condition into CONDITION1_HERE's match expression?

--
Joel Kalvesmaki
Director, Text Alignment Network
http://textalign.net