Putting the Brakes on SharePoint with jQuery – Or Not (Some More)

 eshupps 10:01am, Dec 29 from TweetDeck “Sigh – Nobody listens. #jquery isn’t small or efficient. It’s still thousands of lines of javascript behind the scenes people!”

Actually, Eric, because I’m listening, I feel another need to respond! In my previous response (Putting the Brakes on SharePoint with jQuery – Or Not) to the views on jQuery you expressed in Putting the Brakes on SharePoint with JQuery, I tried to respond to your empirical testing of jQuery techniques with SharePoint.  However, with a tweet like to one above, I get a little ornery.  You’ve got a lot of people following you and probably listening to you and this type of absolute statement isn’t really useful.

jQuery is one of the shiny new pennies on the scene: no debate.  As I pointed out in my prior post, nothing comes for free.  The ease of implementation that jQuery provides requires overhead, and that overhead means some bytes down the wire.  I continue to say that the bytes down the wire are the only overhead imposed on the server itself. This *can* be a good thing, as certain processing can be distributed from the server to client machines.

The choice to use jQuery for any given task should be an informed one.  Yes, you will be sending “thousands” of lines of JavaScript (that’s 4376 un-minified, commented lines of JavaScript in jquery-1.3.2.js, or 19 minified, commented lines in the jquery-1.3.2.min.js version – what does number of lines mean, anyway?) to the client browser, just like SharePoint itself does with core.js and lots of other JavaScript files, as needed.

So what do words like “small” or “efficient” even mean, really?  In comparison to what? I started programming in 16kb.  Does that mean anything bigger is bad? No way, baby, I love having gigabytes of RAM available. But that doesn’t mean that I should use them all to add a fade in effect to some text.  As developers, we owe it to our clients to do things as efficiently as we can given the tools at our disposal.  This is always limited by things like time, money, skills, available software tools, requirements, etc.

 jthake 10:08am, Dec 29 from Tweetie “@eshupps jquery is going to still b used regardless of warnings compared 2 dev :-( mainly due to speed to implement & availability of devs”

“Warnings” is the wrong word here. “Knowledge” would be good.  We need to understand the tools that we use. Period. jQuery is useful if you want to improve the user experience on the client side in certain situations.  “Development” (I continue to get a kick out of the fact that anything other than Visual Studio-based code isn’t considered development.  Is this a Microsoft thing?) also has its time and place.

We’ve all seen bad code written in C# for SharePoint.  Whether it doesn’t dispose of objects properly, or it reads and writes directly into the SQL database or whatever, the same type of “warnings” are important.

The question is how we, and I mean each of us individually, not we collectively – there’s no one answer – can make good decisions when we try to solve specific business problems with the technology we have at our disposal.

TiVo Desktop 2.8 with Windows 7 (Again, But Maybe Finally?)

In a previous post, TiVo Desktop 2.7 with Windows 7, I thought I’d hit on a fix for getting the TiVo Desktop software running right with Windows 7.  Alas, my joy was premature.

I kept getting errors both in trying to transfer shows from my TiVo to my PC as well as when I tried to play old shows on my PC (“Windows Media Player encountered a problem while playing the file”). Looking into C:\Users\Marc Anderson\AppData\Local\TiVo Desktop\Logs at TiVoTransfer.log, I saw repeated errors like this:

Error 2009-12-25:23-01-01.522-05:00 0x28B0 RegistryHelper.cpp, MediaAccessKeyUtils::HKEYHelper::openPath, 90 |  RegOpenKeyExA(path=Software\TiVo\SharingKeys, samDesired=131097) failed: err=2
Info 2009-12-25:23-01-01.522-05:00 0x28B0 TiVoToGoKeys.cpp, TivoToGoKeys::GetSharingKey, 78 |  key is empty: err=TiVoKeyHelper Exception(SharingKeyHelper::decrypt(58)): "Error: Unexpected!"
TiVoKeyHelper Exception(MediaAccessKeyUtils::HKEYHelper::openPath(92)): "Error: 2 during RegOpenKeyEx!: path=Software\TiVo\SharingKeys"

Info 2009-12-25:23-01-01.522-05:00 0x28B0 TivoTransferApi.cpp, CTivoTransferApi::AddDownload, 167 |  GetMediaKey() returned empty MAK
Info 2009-12-25:23-01-05.204-05:00 0x29B8 DownloaderCb.cpp, DownloaderCb::start, 88 |  started: <a href="http://192.168.1.105/download/Dollhouse.TiVo?Container=%2FNowPlaying&id=2476305&Format=video/x-tivo-mpeg">http://192.168.1.105:80/download/Dollhouse.TiVo?Container=%2FNowPlaying&id=2476305&Format=video/x-tivo-mpeg</a>
Error 2009-12-25:23-01-05.719-05:00 0x29B8 DownloaderCb.cpp, DownloaderCb::error, 81 |  <a href="http://192.168.1.105/download/Dollhouse.TiVo?Container=%2FNowPlaying&id=2476305&Format=video/x-tivo-mpeg">http://192.168.1.105:80/download/Dollhouse.TiVo?Container=%2FNowPlaying&id=2476305&Format=video/x-tivo-mpeg</a> failed: error=4

As you can see, the issue seems to be with getting the value for the Media Access Key (MAK) and decoding it.  FYI: The MAK is stored in the registry at HKEY_CURRENT_USER\Software\TiVo\SharingKeys.

Ok, so now I’m starting to do exactly what there is so much of out there on the Web: speculation about arcane details of the problem, what *might* be causing it, and what *might* solve it.

I spent a lot of time over the last few days Binging for solutions, and it took a lot to finally cut through all of the approbrium and misinformation to come up with something that a) seems like it works, and b) sounds like it actually makes sense.

The solution that seems to be working is relatively simple: Go to the C:\Program Files\TiVo\Desktop folder and set all of the executables to Run as Administrator.  (Right click each file, choose Properties, then the Compatibility tab.  Toward the bottom of the tab, check the “Run this program as an administrator” option.)  No, you shouldn’t need to do this, but it seems to have solved all of my issues.  I’ll keep my fingers crossed.  More Dollhouse episodes are on their way over to my laptop as I type…

Thanks to Nunya_Binnez for the tip in the TiVo forums on this fix.

Putting the Brakes on SharePoint with jQuery – Or Not

Eric Shupps posted what some folks have considered a provocative article yesterday to his blog entitled Putting the Brakes on SharePoint with JQuery.

First of all, I’m not going to trash Eric here or say that he is misguided or any of the other Internet flame-a-thon techniques.  Eric knows what he is talking about; I just want to offer my perspective on the thoughts he has shared.  Eric is a SharePoint MVP – I’m just a shlub out here doing what I can to rid the world of non-collaborative applications.

On many levels, I think Eric and I can agree.  Bad code is bad code is bad code.  There’s just no way around that.  (Patient: “Doctor, doctor, it hurts when I do this.”  Doctor: “Don’t do that”.)  However, there is more than one way to skin a cat (which is really a horrible analogy when you think of it: what can you do with a skinless cat?) and you should consider all of the tools at your disposal for any given task.

One of the new tools in our arsenal these days is jQuery.  Yes, I said “ONE of the new tools”.  I’m particularly enamored of it because I find that I can do things from what I call the “front parlor” or the “Middle Tier” that I didn’t have good ways to implement before.  In many cases, the powers that be have shut off access to the back end and there is not an option to deploy managed code to the server.  jQuery, specifically working with the Web Services as I do with my jQuery Library for SharePoint Web Services, allows us to – dare I say it — “get around” these constraints.

One of the benefits of client-side code that few people talk about is the ability to offload some of the processing to the largely dormant CPU sitting on the user side.  (I’m searching for aliens with SETI@Home as I type, and I see nary a flicker.)  With judicious use of client side code, we can actually reduce the load on the server and let it do more “serving” rather than calculating.

So, let’s get to brass tacks.  What specifically about Eric’s post has gotten me fired up to write this post?

Will It Scale?

Eric’s question of “Will it scale?” – Back to my point above about the supercomputers sitting on our desks (mine is a paltry old Dell laptop, by the way, with an Intel Core2 T5500 CPU running at 1.66GHz – about time for an upgrade).  The scaling in this case needs to happen on the client side.  We’re asking the client computer to do more, not the server in many cases.  Sure, using AJAX or RPC puts a load on the server which absolutely needs to be considered carefully, but again, we’re asking the relatively dormant user computer to do more, and asking the server to do less to provide a richer user experience.  (I hope the goal is a richer user experience and not just a bunch of spinning, flaming icons like circa 1996. Paul Daro – your demos live on in my memory!) So the key question here is what the *client* computers’ profiles are.  We’re not asking the server to do anything other than send a few more bytes per request down the wire.

Content Editor Web Part (CEWP) Bugaboo

I think that the CEWP taking 4 seconds is some sort of bugaboo.  If this was actually the case pervasively, we and/or Microsoft would have all figured a way around it by now.

Simple jQuery Test: Alternating Background

The test to change the background color of every other item in the list view is sort of a weird example, but let’s go with it.  In this example, as I see it, you have four implementation options:

1. Don’t do it – This is one option that we should always consider.  Regardless of what the client wants, should they actually do it?  Does this contribute to the user experience? Does it make the site better? (OK, I’m being a little bit boorish here, but consider it.)
2. Use CSS – A simple adjustment to the CSS would accomplish this task nicely.  For the record, this is what I would do in this example.
3. Use jQuery, as Eric does in his example – OK, so we decide to use jQuery.  Eric says that the page takes a second (or less) longer to load.  I’m wondering about this, because by using the $(document).ready function, the page ought to load and *then* the DOM manipulation should start.  The only discernable load different ought to be caused by the additional bytes being sent.  In most enterprise environments this should be negligible.
4. Write a custom, deployed Web Part – This might be the party line solution, though totally overkill for this example.

My point here is that there are four (and you may think of options 5 and 6 and…) options.  No one of them is the solution for every situation.  For this to be a fair test, we’d need to implement each of the four approaches and benchmark them against each other, taking into account many other variables, like network topology, geographic distribution of the users, target browser types, different client machine characteristics (CPU speed, monitor type, etc.), and on and on.  *Any* solution is going to add some processing time; nothing comes for free.

Concurrent User Test

In this test, Eric “configured a single-page web test in Visual Studio Team Test and dropped it into a load simulation of 100 concurrent users over a three minute period”.  To me, this is a highly unrealistic test.  Here’s why: jQuery is a client-side toolset.  The only way to test it realistically is to have 100 client machines available to you, humming along at a realistic load level that represents the actual user community.  No loading on a server is going to give you a realistic read.  So adding the 101st, 102nd, 103rd, user to this test would continue to degrade the performance.

Test, Test, Test

On this Eric and I agree, but I expect that my view is a bit different.  Yes, test, test, test, but there is no replacement for real world experience.  I admit it, I’m an old guy with grey hair.  I’ve worked with more programming languages than I could ever count on probably an equally mind-boggling number of hardware platforms.  There are some things which are good ideas and there are some things which are bad ideas.  You can test, test, test, but I would argue that there are whole categories of solutions that should never be built in the first place.  I’ve had the [good, bad] fortune to be asked to fix many of these over my career, and SharePoint is no different in that respect.  I’ve seen some just plain offensive things done with SharePoint by people who have all the credentials in the world (yes, even MVPs and Microsoft Gold Partners).

There’s no substituting youth and vigor for experience some of the time.  One of the great things about the SharePoint community is all of the bright young players it attracts, and I defer to that talent where it is merited.  Smarts is smarts, and I like to think I know how to recognize ‘em.

So, yes I love what jQuery lets me do, but there are all sorts of things that I just wouldn’t want to try because they would be bad ideas.

Conclusion

Eric, if you wanted to start a debate or make people think with your post (and I hope you did), then you’ve accomplished your object.  That’s the wonderful thing about them there InterWebs: we all get to say what we want and anyone can decide on their own if they want to read and/or listen.  There have been some Twonversations about your post, and you’ve provoked me to write this one.  Maybe someday we’ll have the chance to work together and talk about the trade-offs of all of these approaches, and I’d relish that opportunity.

UPDATE 2009-12-29: If you’ve read this far, then you’ll probably be interested in my follow on post: Putting the Brakes on SharePoint with jQuery - Or Not (Some More).

A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): The SPSetMultiSelectSizes Function

Cross-posted from EndUserSharePoint.com…

SPSetMultiSelectSizes is a function in the jQuery Library for SharePoint Web Services that lets you set the sizes of multi-select picker boxes based on the values they contain. This may sound trivial, but because of the way SharePoint constructs the pickers as compound controls, it’s less straightforward than you might think.

Background

In an old post on my blog, I sketched out how you could set go about Setting Multi-Select Widths in a SharePoint EditForm.aspx Using JavaScript.  The code I posted worked just fine, but took some manual tweaking every time you wanted to use it.  The basic idea is this: When SharePoint renders the multi-select control, the <div>s which contain the selects have a fixed width of 143px.  (Who knows where *that* number came from?!?!)  This is all well and good in the example below.  All of the states fit well inside the <div>s and are quite legible.

But what about the case where the values in your multi-select column are much longer? In the example below, I’m showing a multi-select column which takes its values from the list of Web Services operations which the jQuery Library for SharePoint Web Services currently supports. (Yes, I keep track of things in SharePoint lists.  Isn’t that wonderfully recursive?)  As you can see, it would be very easy to choose the wrong value from among those which start with “GetGroupCollection” unless you scroll to the right, which feels cumbersome at best.

So what I wanted to do was to build a function into the library to deal with this better, and now I have SPSetMultiSelectSizes in v0.4.8ALPHA1. Sure, it’s an alpha, but it works; give it a whirl.

This function led me on several wild goose chases. At first, I couldn’t for the life of me think of how I could reliably figure out what the right width should be. I wrote a post on my blog (Setting Multi-Select Picker Widths in a SharePoint Form Reliably) basically saying “Help!”. To make the function work regardless of the fontSize, fontFamily, fontWeight, etc., that a site may be using, I knew that I couldn’t take any shortcuts. After going back and forth with the ideas I had in that post, plus several others, it finally occurred to me that I could take advantage of the jQuery clone() function for this. What I really needed to do was to clone the existing select, tweak a few of the clone’s CSS attributes, and then use it to determine the best width for the multi-select picker boxes.

Here’s what I’ve come up with for v0.4.8ALPHA1. I expect that it will evolve a bit as it gets some real use, but the fundamental logic is sound.

$.fn.SPServices.SPSetMultiSelectSizes = function (options) {
      var opt = $.extend({}, {
            multiSelectColumn: ""
      }, options);
      // Create a temporary clone of the select to use to determine the appropriate width settings.
      // We'll append it to the end of the enclosing span.
      var possibleValues = $().find("select:[Title='" + opt.multiSelectColumn + " possible values']");
      var selectedValues = possibleValues.closest("span").find("select:[Title*=' selected values']");
      var cloneId = "SPSetMultiSelectSizes_" + encodeColumn(opt.multiSelectColumn);
      possibleValues.clone().appendTo(possibleValues.closest("span")).css({
            "width": "auto",        // We want the clone to resize its width based n the contents
            "height": 0,                  // Just to keep the page clean while we are using the clone
            "visibility": "hidden"  // And let's keep it hidden
      }).attr({
            id: cloneId,                  // We don't want the clone to have the same id as its source
            length: 0                     // And let's start with no options
      });
      var cloneObj = $("#" + cloneId);
      // Add all the values to the cloned select.  First the left (possible values) select...
      possibleValues.find("option").each(function() {
            cloneObj.append("<option value='" + $(this).html() + "'>" + $(this).html() + "</option>");
      });
      // ...then the right (selected values) select (in case some values have already been selected)
      selectedValues.find("option").each(function() {
            cloneObj.append("<option value='" + $(this).html() + "'>" + $(this).html() + "</option>");
      });
      // We'll add 5px for a little padding on the right.
      var divWidth = $("#" + cloneId).width() + 5;
      // Subtract 17 from divWidth to allow for the scrollbar     for the select   
      var selectWidth = divWidth - 17;
      // Set the new widths
      possibleValues.css("width", selectWidth + "px").parent().css("width", divWidth + "px");
      selectedValues.css("width", selectWidth + "px").parent().css("width", divWidth + "px");

      // Remove the select's clone, since we're done with it
      $("#" + cloneId).remove();
};

If you don’t want to understand the details of the jQuery above, here it is in pseudocode.

• Based on the column’s DisplayName on the form, find the two selects in the boxes in the multi-select picker
• Clone the select in the left box (“possible values”) and append it to the <span> which encloses the compound control
• Change the CSS on the cloned select so that its width automatically adjusts based on its contents (this is what we’re used to selects doing most often)
• Load all of the possible values into the clone. We need to grab the values from both the left (“possible values”) select and the right (“selected values”) select. By taking this approach, the logic works whenever it might be applied.
• See what the width of the clone is and make a couple of small adjustments for the scroll bar and adding a little right side padding
• Set the widths of the two boxes (actually a select wrapped in a div for each)
• Remove the clone from the DOM, since we’re done with it

So, what does all of this work that I went through actually get you? Well, it may not seem like much, but it’s another arrow in your quiver to use in the battle against GIGO.

Example

Going back to the example above, we’d like to have the multi-select boxes in the “Web Service Operations” multi-select picker set just wide enough so that we can see all of the values without scrolling.

Here’s what the picker looks like “out of the box”…

…and after making the call to SPSetMultiSelectSizes:

Syntax

As with all of the functions in the jQuery Library for SharePoint Web Services, everything is put in place from the UI or SharePoint Designer. There’s nothing to install server-side. You simply need to add references to the core jQuery library and the jQuery Library for SharePoint Web Services and then call the function. See the documentation on the Codeplex site for more details on how to set things up.

SPSetMultiSelectSizes currently takes just one option:

 where multiSelectColumn should indicate the column’s DisplayName on the form.

$().SPServices.SPSetMultiSelectSizes({
    multiSelectColumn: "Web Service Operation"
});

 

I expect I’ll be adding a few more options along the way. A few things that come to mind:

• Allowing you to specify an absolute width rather than having the function do the calculations for you
• Specifying whether you want to allow the picker boxes to shrink in size, as they will currently if you have only short values

Conclusion

While this function doesn’t make any calls to the SharePoint Web Services, it seemed like a natural addition to the library. My initial inclination was to automatically call it from $().SPServices.SPCascadeDropdowns, but I’m not sure that makes sense, as it’s pretty simple to call it separately. As always, I’m interested in what you think and what enhancements you’d like to see.

Going to Review a FREE Book from Packt Publishing: SharePoint Designer Tutorial

Over the weekend, I received a free copy of the book SharePoint Designer Tutorial: Working with SharePoint Websites by Mike Poole.  They have asked me to review it here on my blog, and I never turn down a free book.

Is that enough for the FTC? Check out the article FTC: Bloggers who shill must also tell to read more about the new FTC rules around so-called “blogola”.  I can guarantee you that I am no shill, but who wants to run afoul of the gummint?

One unfortunate thing I noted right off the bat (I thought maybe they had sent me the wrong book) is that, on the copy I received, the text is set up like this on the cover and similarly on the spine:

Maybe it’s me, but if I were to glance at this on a bookshelf, I wouldn’t think it was about “SharePoint Designer”, but instead was about SharePoint and *for* designers (meaning graphic designers, layout artists, etc.)

If anyone out there has read this book and has input on it, leave me a comment, and watch for a review later in this space.

Font Usage Surveys for the Windows, Mac, and Linux Platforms

As I was working through the potential solution to the poser I posted yesterday (Setting Multi-Select Picker Widths in a SharePoint Form Reliably) last night, my addled brain wasn’t coming up with a good list of fonts to test my algorithm.  I turned to the interWebs and found a slick site which has a great set of surveys of font usage for various platforms.

If you voyage on over to the CodeStyle Web Site, you’ll find all sorts of great information.  What I was looking for was on the CSS font sampler and survey page, which gives you all of this delicious content to consume:

Windows font survey and font survey results

Mac font survey and font survey results

Linux font survey and font survey results

Combined survey results for all platforms

Classification of the most common fonts by generic font family:

• Serif fonts: survey results
• Sans serif fonts: survey results
• Fantasy fonts: survey results
• Cursive fonts: survey results
• Monospace fonts: survey results

CSS font family glossary

Anchor Points: Font foundries & sources

If you visit the font survey page for your platform, you can contribute to the survey by letting a little Java applet scan your machine for the installed fonts.

I’m not sure how this site fits into the general value scale of what’s out there on the Web, but it seems like a great, valuable set of information that looks valid to me.

Setting Multi-Select Picker Widths in a SharePoint Form Reliably

In an old post, I sketched out how you could set go about Setting Multi-Select Widths in a SharePoint EditForm.aspx Using JavaScript.  The code I posted there worked just fine, but took some manual tweaking every time you wanted to use it.  The basic idea is this: When SharePoint renders the multi-select control, the <div>s which contain the selects have a fixed width of 143px.  (Who knows where *that* number came from?!?!)  This is all well and good in the example below.  All of the states fit well inside the <div>s and are quite legible.

But what about the case where the values in your multi-select column are much longer? In the example below, I’m showing a multi-select column which takes its values from the list of Web Services operations which the jQuery Library for SharePoint Web Services currently supports. (Yes, I keep track of things in SharePoint lists.  Isn’t that wonderfully recursive?)  As you can see, it would be very easy to choose the wrong value from among those which start with “GetGroupCollection” unless you scroll to the right.

So what I’d like to do is build a function into the jQuery Library for SharePoint Web Services to deal with this better.  It will become an option on $().SPServices.SPCascadeDropdowns, but clearly it will have usefulness just as a standalone function.  I want this new function to work automagically regardless of the font family and font size.

I’ve asked some of the smart design folks I know, like Michael Greene (@webdes03) and Marcy Kellar (@marcykellar) whether they have any ideas.  Since these bright folks didn’t come up with an instant “Oh, you just…” answer, I don’t feel too bad about not seeing an approach immediately.

It’s pretty easy to figure out what the longest possible value is, and the code below works well. The issue is that the 10px multiplier is just a hack. What I’d like to be able to do is determine the average width of a character in the select and multiply by that. For instance, if the select font-size is 20px, then the 10px isn’t going to work well. (Note that I’ve intentionally left the code very verbose below just to show what I’m doing.)

var maxWidth = 0;
$("select:[Title='Web Service Operation selected values']").find("option").each(function() {
  if($(this).html().length > maxWidth) maxWidth = $(this).html().length;
});
$("select:[Title='Web Service Operation possible values']").find("option").each(function() {
 if($(this).html().length > maxWidth) maxWidth = $(this).html().length;
});
$("select:[Title='Web Service Operation possible values']").parent().css("width", 10 * maxWidth + "px");
$("select:[Title='Web Service Operation possible values']").css("width", 10 * maxWidth + "px");
$("select:[Title='Web Service Operation selected values']").parent().css("width", 10 * maxWidth + "px");
$("select:[Title='Web Service Operation selected values']").css("width", 10 * maxWidth + "px");

So, does anyone out there have any good ideas about how to decide what that 10px multiplier ought to be? Remember that it needs to work whatever the font-family and font-size are.

UPDATE 2009-12-18 21:30 – I had a thought on this.  It might work to add a hidden <div> to the page that has 100 characters styled exactly the same as the selects, check the width of that <div>, divide by 100 and then use that result as the multiplier.  It wouldn’t be exact, but it ought to be darn close.  I’ll pursue this approach until I hear something smarter, which I no doubt will!

Podcast About SharePoint, jQuery, Web Services, etc. with Jeremy Thake of the SharePoint Dev Wiki

Jeremy Thake and I had a nice chat yesterday.  Morning my time, evening his; we could hardly be further apart, him in Perth, Australia and me here in Boston, MA, USA.

Despite the time difference, I fully enjoyed the conversation.  I know that Jeremy knows his stuff, having followed his work through Twitter (@jthake) and on the SharePoint Dev Wiki. It’s interesting getting to talk to someone you only know through typing.  I thought perhaps we might not see eye to eye on some of my thinking about SharePoint and where I see it heading, but we seemed to after all.  As is usually the case once you get me talking, the conversation freewheeled around a bit.  Ostensibly it was about my jQuery Library for SharePoint Web Services, but we managed to cover a lot more ground than that.

If you have a spare 45 minutes or so, give the podcast a listen.

SharePoint 2010 and the jQuery Library for SharePoint Web Services

I decided it was high time to take a look at how my jQuery Library for SharePoint Web Services might hold up in SharePoint 2010.  After all, it’s a whole new product, everything’s new and improved, etc.  Except it turns out that many things are exactly the same.

This is actually not bad news.  For instance, even though the forms to create, edit, and view list items (NewForm, EditForm, and DispForm) look quite a bit different in SharePoint 2010, they have almost exactly the same HTML structure. In SP2010 they generally pop up in modal windows, but the page structure is the same.

This isn’t just good news for my jQuery Library for SharePoint Web Services, it’s good for anyone who has done the work to create scripts that enforce business rules on their forms.  Based on my very quick pass today, I’m guessing that most form scripts will continue to work as they have or may need minor tweaking.

jQuery Library for SharePoint Web Services v0.4.7 Released

I released v0.4.7 of the jQuery Library for SharePoint Web Services today. This release primarily contains enhancements to existing functions, but also a new set of operations for the Meetings Web Service.

The big headlines are:

• Support for multi-select parent columns in $().SPServices.SPCascadeDropdowns
• “Secondary” relationshipList support in $().SPServices.SPCascadeDropdowns
• A new completefunc option for most of the functions (where it was going to be useful)
• General bug fixes and debug mode improvements

Just a reminder: If you are still using a version prior to v0.4.6, I *highly* recommend an upgrade, as I made some significant performance improvements in $().SPServices.SPCascadeDropdowns and $().SPServices.SPDisplayRelatedInfo.

Release Notes

New Functionality

Issue Tracker Item	Function	Operation	Description
NA	$().SPServices.SPDisplayRelatedInfo	NA	Added new options numChars and matchType
5010	$().SPServices.SPCascadeDropdowns	NA	Added support for secondary relationship lists
5012	$().SPServices.SPCascadeDropdowns, $().SPServices.SPDisplayRelatedInfo, $().SPServices.SPLookupAddNew, $().SPServices.SPRequireUnique	NA	Added a completefunc option
4196	$().SPServices.SPCascadeDropdowns	NA	Added support for multi-select parent columns

New Operations

Web Service	Operation	Options	MSDN Documentation
Meetings	AddMeeting	organizerEmail, uid, sequence, utcDateStamp, title, location, utcDateStart, utcDateEnd, nonGregorian	Meetings.AddMeeting Method
	CreateWorkspace	title, templateName, lcid, timeZoneInformation	Meetings.CreateWorkspace Method
	RemoveMeeting	recurrenceId, uid, sequence, utcDateStamp, cancelMeeting	Meetings.RemoveMeeting Method
	SetWorkspaceTitle	title	Meetings.SetWorkspaceTitle Method

Bug Fixes and Efficiency

Issue Tracker Item	Function	Operation	Description
4971	$().SPServices.SPCascadeDropdowns	NA	The & sign causes problem
NA	$().SPServices.SPDisplayRelatedInfo	NA	Improved debug mode when relatedList column doesn’t exist.
NA	$().SPServices.SPLookupAddNew	NA	Added in some better debug mode code. It wasn’t trapping in any obvious way if the column you called it with wasn’t actually a lookup column. Now with debug mode enabled, if the column isn’t a lookup column, you’ll get a message, like with the other debug mode-enabled functions.
5011	$().SPServices.SPDisplayRelatedInfo	NA	Improved formatting for calculated columns by removing leading value type indicator (e.g., string;#, float;#, datetime;#)