Re: [xsl] XSL resources - Flat to hierarchy - Common ancestors

Subject: Re: [xsl] XSL resources - Flat to hierarchy - Common ancestors
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Tue, 27 Jul 2004 07:54:07 -0600
Hey Ben,

I have about 10 minutes before my day becomes completely consumed by the launch schedule of today's Saxon.NET Phase One Beta 1 release. Let's see if there is anything I can help you with in that time....

Ben Simkins wrote:
Not wishing to quit on a winning streak...

That's the kind of attitude I love to see!!! :D

What do the variable and the parameter do?

The general difference between a variable and a parameter is, in essence, one is static and one is dynamic... Or better stated one is set internally by either hard coding a value to a string, element or attribute value (which I guess sort of adds a dynamic element to it... but I'll keep with the analogy for now as the value of that variable can not be set from anywhere outside of the stylesheet other than an XML file associated with the stylesheet at runtime via the document function or the source file set by the transformation process and once the processing of the stylesheet begins the value it is set to or the process that builds the value (like a temporary tree) can not be changed), or nodeset where as the other can be changed at the beginning of a process or sub process within the stylesheet. If its not already obvious xsl:variable is the static part of this analogy and xsl:param is the dynamic.

As I mentioned xsl:param can be changed at the beginning of any process or sub process within the stylesheet but it must take place before any of the processing within a template begins. If, for example, you passed a value to a template via the xsl:with-param child element of xsl:apply-templates or xsl:call-template then there would have to be a parameter (xsl:param) with the same name as that specified in the name attribute of xsl:with-param and there can be no other child elements of xsl:template that precede any of the xsl:param child elements. This same "preceding" rule does not apply to global params that are set before the first xsl:template element but it is still good practice to place them before any global xsl:variables to ensure that you develop the habit. It's one of those errors that depending on the processor being used doesnt always present itself in a format that states "I have to be first! I gotta! I gotta! I gotta!" and as such can get you into a very frustrated mood really quickly if your not careful about the proper placement... theres nothing worse than having to dig through log files or console output trying to find out why your stylesheet isnt working only to find buried 1700 lines up a half line entry that may or may not even specify where the problem is taking place which can be even more frustrating if you are importing a ton of stylesheets...

Wouldn't <xsl:with-param name="MenuId" select="@MenuId" /> also work in the first "Menu" template ?

Sure, as long as you created an xsl:param element (following the order rules above ;) in the first template that can then be updated when the containing template pulls the winning lottery ticket and is given a run-time supply of elements to devour and the "command" to update the xsl:param element that has "x" for a name with the value specified in the xsl:with-param that came along for the ride...

I take it this isn't the same as a parameter which would be passed in on a query string (or whatever the xsl equivalent is)?

Well, however you get the value of the query string to your processor and then from the processor into your stylesheet then, yes, this is the same concept.. except the values passed in from outside the processor are of a global nature allowing access to their value from any calling template or imported template that is part of the transformation process...

What I want to be able to do is to pass a MenuId to the xsl and have it
collapse everything except the branch on which that Menu is (in case
anyone wondered, the target use is for a frameless web site with 400+
menus, where I don't want to display all 400 menus on every click, and
where I don't want to loop through them on every click either)

No problem... just figure out how to get the processor you are using to send in the proper name value pair and your golden... just check the value of the param against the value of the MenuId during the normal processing and when they match make that particular menu visible using whatever chosen client side method you use...

Is that what this example does?

It can, yes...

->If it isn't clear what I mean by 'collapse everything but', I'll send an example

Its clear, and yes you can make this happen... with the way you handled the proper implementation of template matching I have no doubt youll be up and running with this in no time...

K, my 10 minutes are up... Good luck with this!

Best regards,


Current Thread