Thanks for your comments. I'm glad you're digging in and looking at the code. It's rather a complex bit of xslt but is well commented and (I hope) a useful learning vehicle.

The use of string() is to avoid the problem of the /macro/source parameter not being set, or even being null. This is a sneaky short-hand way of avoiding problems and it common in XSLT. Also remember that XSLT is not stronly typed.

Thus, the $source variable will either have a value of -1 (which means all nodes) or whatever value was passed in from the macro parameter. If the macro parameter is missing or empty, it will default to -1.

It does seem that I don't need to convert the $source variable (which will always have a value because of the ps:getParameter() function) to its numeric equivalent with the number() function, but I'm sure I needed the conversion at one point to avoid some situation I don't now remember :) I might be able to do without it, but it does no harm to leave it in.

A lot of the code in XSLTsearch is there to ensure it will work properly in every situation and even with bad (or missing) input values. You could, for instance, pass NO parameter values at all (just empty strings) and it would work just fine. Or, you could remove the macro parameters from the Macro entirely. Again, it would just work. In my personal projects I don't usually go to so much effort but in a public project that is used by thousands of people I want it to be much more forgiving.

cheers,
doug.

Hi Douglas,

Sorry, I don't mean anything offensive. XSLTSearch is such a fantastic package. I add the topic here just want to the problems got fixed, so it can be better.

The problem is not about 'string()', it is about the type of macro parameter 'source'. You could test it yourself. Add the following line at the very beginning of the main template, you will get 'NaN', instead of the source node ID, no matter what was passed to it (-1 or other number) .

<xsl:value-of select="$source" />

That is because, the type of the macro parameter is a 'contentTree', and the value of the parameter will be extracted to something like

<source nodeID="1060">
<node id="1060" version="a27d163f-828e-420e-9758-6db52acae492" 
parentID="-1" level="1" writerID="0" creatorID="0" nodeType="1047"
 template="1039" sortOrder="3" createDate="2007-06-21T14:09:32" 
updateDate="2007-06-21T14:10:43" nodeName="DE Frontpage" 
urlName="de-frontpage" writerName="Administrator" 
creatorName="Administrator" 
nodeTypeAlias="wwFrontpage" path="-1,1060">
<data alias="bodyText">...</data>
<data alias="headerImage">/media/21/header.png</data>
</node>
</source>

I think the type of the macro parameter should be 'number' or 'text' or 'contentPicker', so that the parameter can be extracted to

<source>1060</source>

You could see An overview of all the macro parameters on umbraco books for details how different type of macro parameters are extracted in XSLT.

Sorry for my poor English, I think I haven't expressed the issue clear in the previous post. Wish I am clear this time.

Hi, Wayne,

You're absolutely right, the "logic" of my code is extraneous the way I've handled it... it will either use GetXmlAll() if no parameter (or an empty parameter) is passed in, and in every other situation will go to the xsl:otherwise statement. Nice catch.

The functionality of the script is still fine, but there's more code there than is needed to do the job.

I pass in a contentTree so that the $source variable contains the content to search through, not only an id. That was by design but I must have been sleeping when I coded the xsl:choose statements :)

Thanks again!

cheers,
doug.

is working on a reply...