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,
<M:D/>