1,804 articles and 15,744 comments as of Thursday, December 23rd, 2010

Thursday, March 4, 2010

Unlocking the Mysteries of Data View Web Part XSL Tags – Part 13: Miscellaneous – String Functions

Author: Marc D. Anderson
http://mdasblog.wordpress.com

In the last article, I talked about teasing out the various parts of the values in Person or Group column values. To do this, I relied on the substring functions which are available to us in XSL.  In this article, I’ll go over a few of those string functions and show you how useful they can be.

What you create a new variable with <xsl:variable> or use <xsl:value-of> to display the contents of a variable or column (among other things), you have many different options available to you in the select attribute. When you first type the equal sign after the select, you’ll see a dropdown menu in SharePoint Designer.  The first option in that dropdown is XPath Expression Builder:



When you click on the XPath Expression Builder, you can build up more complex XPath expressions with the Builder to help you through the process.  In this article, we’re going to focus on a few of the Text / String functions:



As you click on each of these functions, you’ll see how to use them on the right side, as in the screenshot above showing the concat definition.  I won’t repeat those definitions here as there are many other great posts out there that cover them. Instead, I’ll go over a few tricks you’ll need to know to use these functions to do cool stuff.  If you’re used to using string functions in other languages, you might get frustrated with this set of functions.  I know I was early on, and it took some getting used to them before I was able to crank out useful XPath expressions easily.

substring-before and substring-after

These twins work great together.  Let me repeat an example from the previous article on Person or Group columns.  Here’s what a typical Person or Group column value might look like:



If you don’t want to display the user’s name as a hyperlink, you can substring out the actual name:

<xsl:variable name="UserName" select="substring-after(substring-before(substring-after(@Author, ‘ID=’), ‘&lt;’), ‘&gt;’)"/>

This was probably clear as mud when I showed it before, but let’s break it apart a little.

First, we grab the text after the ‘ID=’ string:

substring-after(@Author, ‘ID=’)



Then the text before the ‘<’ in the remaining text:

substring-before(substring-after(@Author, ‘ID=’), ‘&lt;’)



And finally then the text after the ‘>’ in the remaining text:

substring-after(substring-before(substring-after(@Author, ‘ID=’), ‘&lt;’), ‘&gt;’)



Hopefully the pictures make it a little more obvious how we’re whittling down the big long string into what we want.

string-length

string-length is especially useful when we want to test for the existence of a value.  Keep in mind that all values coming back to us in the DataSource are always coming stored as text in XML.  SharePoint Designer parses apart the XML for us so that we don’t have to think about the actual representation.  When a value is “empty” (in other languages you might test for a null value or an undefined value, etc.), then it has no value. We can for the existence of the value by checking the string-length:

<xsl:choose>
<xsl:when test="string-length(@Title &gt; 0)">
<xsl:value-of select="@Title"/>
</xsl:when>
<xsl:otherwise>
The Title is empty.
</xsl:otherwise>
</xsl:choose>

translate

translate lets you replace one character with another in a text value.  Here’s one spiffy trick you can use it for: converting a string to all upper case for reliable comparisons between strings.

<xsl:variable name="UTitle" select="translate(@Title, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')"/>

What this does is replace the instances of each lowercase letter with their uppercase equivalent.  If you are doing this just for display, then I would encourage you to use a CSS class with text-transform:uppercase, but this trick is great when you need to work with the strings in your XSL logic.

This is an example of nice little template to keep around in case you need it.  In larger projects, I’ll usually build up a utilities.xsl file and store it in /Style Library/XSL Style Sheets.  In that file, I’ll store reusable utility templates to do things like this uppercase conversion.  Then I include the utility.xsl file in DVWPs wherever I need it using the <xsl:import> tag. (No, I haven’t covered that one in this series.  Yet.)

Obviously, there are a few more of these string functions available to use in your XPath expressions.  I just wanted to show you a few of the little tricks that you can do with them that turn out to be useful over and over again.

In the next article, I’ll go into some more depth on the ddwrt namespace.

Author: Marc D. Anderson
http://mdasblog.wordpress.com

Marc D. Anderson is a Co-Founder and the President of Sympraxis Consulting LLC, based in Newton, MA.  He has over 25 years of experience as a technology consultant and line manager across a wide spectrum of industries and organizational sizes.  Marc has done extensive consulting on knowledge management and collaboration and what makes them actually work in practice.  Marc is a very frequent “answerer” on the MSDN SharePoint – Design and Customization forum.

Entries in this series:
  1. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 1: Overview
  2. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 2: xsl:template
  3. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 3: xsl:call-template
  4. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 4: xsl:with-param
  5. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 5: xsl:param
  6. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 6: xsl:variable
  7. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 7: xsl:for-each
  8. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 8: xsl:sort
  9. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 9: xsl:if
  10. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 10: xsl:choose
  11. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 11: xsl:value-of
  12. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 12: Miscellaneous - Person or Group Columns
  13. Unlocking the Mysteries of Data View Web Part XSL Tags - Part 13: Miscellaneous - String Functions
  14. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 14: Miscellaneous – ddwrt Namespace Functions
  15. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 15: Miscellaneous – Field / Node Functions
  16. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 16: Miscellaneous – xsl:attribute
  17. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 17: Miscellaneous – xsl:comment and xsl:text
  18. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 18: Miscellaneous – Some Math / Number Functions
  19. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 19: Miscellaneous – More Math / Number Functions
  20. Unlocking the Mysteries of Data View Web Part XSL Tags – Part 20: xsl:import
  21. EUSP eBook Store: First SharePoint Title is Now Available
 

Please Join the Discussion

19 Responses to “Unlocking the Mysteries of Data View Web Part XSL Tags – Part 13: Miscellaneous – String Functions”
  1. naveen says:

    hi marc,

    I have two dataview’s in a page in which second data view gets filter value from first dataview using web part connections. the problem i am facing is if there is no rows to display in first dataview, second dataview displays all rows from the list. i want second dataview also should be empty.

    both dataviews are created from different lists.

    appreciate ur help.

    thanks

  2. @naveen: What you’re seeing is the default behavior of Web Part Connections. This is one of the reasons that I never use them. Instead, I set up the selection on the first DVWP to do a redirect back to the same page with the selected value on the Query String. Then I have full control over what is displayed in the second DVWP.

    M.

  3. Ron says:

    Marc,
    I have Same Problem can u point any source where i can get direction to work on your suggestion.

    Ron

  4. naveen says:

    @Marc: it works fine. thanks to u.

    @ron: i will just explain what i have done.. hope this might help u.

    1. open the page in sharepoint designer

    2. make any field as hyperlink in first data view which passes the query string to another dataview.please find the code below

    <td class="ms-vb">
        <a href="https://www.tc.ford.com/ts/operations/IOA/metrics/Hiring/Pages/Consolidated_Hiring_Dashboard.aspx?jobID={@jobID}" onMouseOver="window.status=''; return true"
         onMouseOut="window.status='';return true" style="text-decoration:none; font-weight:bold">
        <xsl:value-of select="format-number(@jobID, &quot;###0.;-###0.&quot;)" /></a>
       </td>
    

    in my case, i used Job ID as querystring.

    3. open common dataview tasks of second data view

    4. click on filter, select field name which u want to use as filter.

    5. now in value field, select “create a new parameter” from dropdown. it will open new parameter window.

    6. provide parameter name and from parameter source dropdown, select query string. now give some name to query string. in my case its “jobID”

    7. use this query string variable in step 2 to pass the filter value to data view

  5. @naveen: Good stuff. Glad you got it working. Check my comment here for another tip.

  6. Ron says:

    Thanks Naveen
    I will Try it

  7. Ron says:

    Hi Naveen
    You Said find the code below but i cant see it can u please post it.

    Ron

  8. Ron says:

    I Have Two DVWPs on Same page dont know how to pass QueryString from one Webpart to another.
    Please Help me how to pass Querystring rest of things are Clear to me.

    ROn

  9. @Ron: You don’t pass the Query String parameter between the two DVWPs; each DVWP should have a parameter defined that grabs the Query String value.

    M.

  10. naveen says:

    @ Ron: actually i have included code in my comment.. i dont know why its been removed.. security might be a reason…

  11. Ron says:

    HI Naveen Try to Replace with > see if it works.

  12. I have updated Naveen’s comment to include his code snippet. — Mark

  13. Ron says:

    Thanks Marc

  14. dawg3294 says:

    Ah, I got it finally. I copied and pasted that code into SP Designer, and kept trying to figure out why it wouldn’t work. Turns out that when I copied it, it used the wrong kind of single quote.

    It’s always the little things that take forever to figure out. :(

  15. Will says:

    Nice article. I have tried the code from Naveen but can’t seem to get it to work with multiple paramters being passed in. I am using SharePoint Designer for some custom data views of lists. So what I have is 3 DVWPs 1 used for lookup, the second displaying the metadata using a paramater(@ID) from the first list, and the third doing a lookup on another data source using a parameter(@lookupcolumn) from the first. @lookupcolumn is a multi-select lookup column on the SharePoint list.

    I am getting the message “This Web Part does not have a valid XSLT stylesheet; Error: A semicolon was expected.”
    My url parameter looks like this:
    .aspx?itemID={@ID}&lookupcolumnvalues={@lookupcolumn}

    I have tried to place a semi colon at various positions, but with no success.

    Any advice? Thanks in advance

    • Will:

      Sorry for the delayed reply. You need to encode the ampersand as &. That’s the semi-colon SPD is looking for.

      M.

      • Will says:

        Thanks Marc,
        However when I started to think about this and I believe there will be a limitation of using this for lookup columns. Since there is a limit on how many characters can be in a url, there is the possibility that not all the items will be carried over. For example, if the lookup list contains Titles with 100 characters and the corresponding list item has 30 items linked to it, the last dozen or so items will be lost, at least with IE’s limit of 2083 limit.
        Of course one solution would be to just use the ID in the lookup column, but this wouldn’t give a value a user would recognize versus the Title field when editing the item that is using the lookup column. Another solution is to do some more customization on the New/Edit form of the item.
        Just sharing some thoughts about this.
        Again, I appreciate the help and great post!

      • Will:

        I missed that you wanted to pass so many values on the Query String. Probably a bad idea for many reasons. Better to pass the ID of the “parent” item (which contains the lookup values), use an AggregateDataSource to include it in your DVWP’s logic, and manage the lookup values there.

        M.

Trackbacks

Check out what others are saying about this post...
  1. [...] allows you to be highly modular in storing your XSL templates for reuse. I mentioned this back in Part 13 briefly, but I should go into it in some more detail. This post will be sort of a twofer: I’ll [...]




Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!