Symphony.

Hello, I'm still not catching the knack of <apply-templates />, heck. My understanding is: template is a sort of dress, which either can be mandatory as first element, and optional as second+ element.

Definition of apply-templates is that it applies templates to all children of the current node. But that behaviour is already built-in, because if the processor matches a template with a node, the first gets applied.

And there are the built-in templates rules, which are applied no matter if a template exists or not.

In usual languages, you have to explicitly output the information. My feeling of Xslt is that it's incredibly sparse, incorporeal and elusive as no language I have seen.

Thanks for any tutoring, hint, suggestion

Hello, I'm still not catching the knack of <apply-templates />, heck. My understanding is: template is a sort of dress, which either can be mandatory as first element, and optional as second+ element.

@Manaus - take a look at this video tutorial. This should give you a good idea on how <xsl:apply-templates/> works.

http://vimeo.com/groups/symphonycms/videos/15234803

@Manaus did the above post help?

Yes, thanks @bzerangue, sorry for the late response (I'm getting old and slow :) Yes it cleaned some aspects of the instruction. Too bad there are not more of those videos.

Bear with me. In the master.xsl, that comes with the basic ensemble, there is a <apply-templates /> tag in the middle of the page. Is that recursive? What does it do? It passes all the xml of the input to the output. So if the default behavior of the processor is transparency (that is, the less you tag, the more you print), you aim to control that stream by [...] ?

@Manaus: Great teaching material for me was the XSLT 1.0 Pocket Reference. Short and precise!

Ok @michael-e I'll give it a scan Thanks

Think of xsl:apply-templates as being a way to control the flow of document processing.

XSLT is a pattern matching language much like CSS. The processor will always start from the top of the document (the root node) and work it's way down the tree (traversing) and matching as it goes. By breaking your document up into templates and using xsl:apply-templates you get to control that flow and tell it what should be processed next. The xsl: apply-templates can be used without specifying the select attribute for a very broad match. However, in most cases you'll use it with the select attribute to specify exactly what you want to match and this is where the real power lies. You can make each template as broad or specific as you like but keep in mind both readability and reusability — if it's something you're likely to need again elsewhere. This form of explicit matching also carries with it the benefit of making your templates much easier to read.

It also provides a timely hook in the process where you can filter, sort, or manipulate the content of the XML document. If you're looking to output a table of results for example you can match the nodes in the XML document, and selectively pluck out only the entries you're interested in and order them accordingly. You may just want nodes with a certain attribute, with a certain value, or output in a specified order. The options are pretty expansive but you get the idea. You can shape the data as you're building the transformation.

Keeping your template files modularised into smaller templates helps to keep things readable, reusable (DRY), and easy to edit in the future — very much inline with XSLT best practices.

Definition of apply-templates is that it applies templates to all children of the current node. But that behaviour is already built-in

Not really. Other than matching on the root node (<xsl:template match="/">) you then have to channel the stream so to speak and tell it what you want to match and transform.

because if the processor matches a template with a node, the first gets applied.

No, it's not the first that's matched but the most specific that wins. So, if you have two templates and one has a more specific pattern than the other the processor will look to use the more specific one.

And there are the built-in templates rules, which are applied no matter if a template exists or not.

There is a built-in rule provided for each type of node in an XML document. These act more like fallbacks in the absence of any more specific rules in the template. Generally you'd always want to be explicit when building your template files so you can read it through and it all makes sense. An implicit approach — leaving things to default handling — relies on the readers' (your future self or others that pick up your code) knowledge of the language defaults and are far more open to misinterpretation or confusion. Always be explicit and state what you want your code to do (but not so explicit that you can't reuse it again :) ).

In usual languages, you have to explicitly output the information. My feeling of Xslt is that it's incredibly sparse, incorporeal and elusive as no language I have seen.

Being explicit is equally good practice in XSLT too. In the absence of specific instruction if will carry on with it's normal flow until it finishes processing the document but it's up to you to channel the flow and tell it what to process and when. It's an incredibly powerful template language when you get to grips with it.

Thanks @ijy, just put in the study queue :)

Well put @ijy! Thanks for the clear explanation. Very, very helpful.