Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Dan 1250 posts 3746 karma points admin c-trib
    May 02, 2012 @ 14:40
    Dan
    0

    Possible bug when specifying start node to search

    Hi,

    This is a much loved and very established package, so it could very well be that I'm interpreting the XSLT incorrectly (particularly as I've done some fairly heavy customisation) but I wanted to put it 'out there' for a second opinion.

    The 'choose' statement around line 121 (version 3.0.4) ends with something like this:

          <xsl:otherwise>
            <!-- search only within the SOURCE node specified in the macro and all of its children -->
            <xsl:call-template name="search">
              <xsl:with-param name="items" select="./descendant-or-self::*[@isDoc]"/>
            </xsl:call-template>
          </xsl:otherwise>

    This is the condition which applies when there is a source node set as a macro parameter, which is, as I understand it, when you want to start your search up through the content tree starting at a particular node.

    I had issues when this condition was met though - it just wasn't returning the anticipated nodes in the search results.  On initial inspection it seems that this condition is instead just returning descendent (or self) nodes from the current node instead of from the selected source node.  I modified it to the following and it now returns what I'd expect:

          <xsl:otherwise>
            <!-- search only within the SOURCE node specified in the macro and all of its children -->
            <xsl:call-template name="search">
              <xsl:with-param name="items" select="umbraco.library:GetXmlNodeById($source)/descendant-or-self::*[@isDoc]"/>
            </xsl:call-template>
          </xsl:otherwise>

    Like I say, I've customised the search script quite heavily, and haven't done a particularly thorough trace of exactly what's happening, but I wanted to see if anyone could verify this as it might be something to change in 3.0.5 if it is indeed a bug.  More than happy to be proven that it isn't! :)

  • Douglas Robar 3570 posts 4670 karma points MVP 6x admin c-trib
    May 02, 2012 @ 15:32
    Douglas Robar
    1

    It should work fine, as long as your macro parameter is using the correct type. I suspect your modified macro uses a 'contentPicker' for the 'source' parameter. XSLTsearch uses the 'ContentTree' property type, which will make the difference of sending in either a single ID or a whole chunk of xml. 

    ...which will make the difference of being able to use the current data (in my code) or having to get the node by id (in your code).

    cheers,
    doug. 

  • Lee Kelleher 3928 posts 15072 karma points MVP 10x admin c-trib
    May 02, 2012 @ 15:33
    Lee Kelleher
    0

    Curious about this too now.  Just downloaded 3.0.4 from the project page, and took a look... and I think you're right - looks like a bug.

    The "./descendant-or-self" wouldn't even use $currentPage, but the <macro> XML (which contains the parameters).

    Good spot, sure Doug will update accordingly.

    Cheers, Lee.

  • Dan 1250 posts 3746 karma points admin c-trib
    May 02, 2012 @ 15:35
    Dan
    0

    Yep, that's probably it.  Thanks for the sanity-check Doug!

    Edit: If you've found the same Lee then I will investigate further, but I did change the datatype of the macro parameter so Doug's answer sounds entirely likely.

  • Lee Kelleher 3928 posts 15072 karma points MVP 10x admin c-trib
    May 02, 2012 @ 15:36
    Lee Kelleher
    0

    Ah-ha, just saw your reply Doug... having the ContentTree property type makes sense! (e.g. it sends the node XML!)

    #h5is :-)

    Cheers, Lee.

  • Douglas Robar 3570 posts 4670 karma points MVP 6x admin c-trib
    May 02, 2012 @ 15:47
    Douglas Robar
    2

    @Lee - I was trying to be clever at the time but if I were to write XSLTsearch again I'd just use a contentPicker and GetXmlNodeById()... nobody (and that includes me from time to time) remembers that there's a contentTree that sends in xml. It's a classic case of being clever rather than being clear.

    While there *might* be a *teeny tiny* performance benefit from sending in the xml rather than having to make a second call to retrieve it, I don't think it's significant and not worth the confusion.

    cheers,
    doug. 

  • Dan 1250 posts 3746 karma points admin c-trib
    May 02, 2012 @ 16:34
    Dan
    0

    I've often wondered what the contentTree macro parameter type does.  The world makes a lot more sense now (how did I miss that it passes through a chunk of XML!?)

    Thanks Doug, always great to learn something new.

Please Sign in or register to post replies

Write your reply to:

Draft