Following up on my post Interesting New Uses for SPDisplayRelatedInfo, I’ve just added two new options to the SPDisplayRelatedInfo function in the first alpha for v0.4.7 of the jQuery Library for SharePoint Web Services.  The function is getting a little overloaded with options, but these two seemed pretty valuable yet not worth breaking things out into a new function.

 The two new options are:

numChars: 0,      // If used on an input column (not a dropdown), no matching will occur until at least this number of characters has been entered
matchType: "Eq",     // If used on an input column (not a dropdown), type of match. Can be any valid CAML comparison operator, most often "Eq" or "BeginsWith"

With these options, you can now use SPDisplayRelatedInfo more flexibly with columns which are not dropdowns or multi-selects, specifically Single line of text or Number columns.

By specifying a number of characters in numChars, you can limit the Web Services calls to find matching items in the relatedList from occurring until there have been at least that many characters typed.

By specifying a different value for matchType, you can change the type of comparison which is done to find matching items.  As noted above, the two most common values will be Eq and BeginsWith, however, there didn’t seem to be any reason not to allow all of the other available CAML comparison operators: Contains, Geq, Gt, Leq, Lt, Neq, etc.  You can see the descriptions for all of these CAML operators in the CAML Query Schema in the SDK on MSDN.

I ran across a great JQuery and SharePoint 2007 blog post yesterday, and I wanted to capture the URL here for later reference. Vedant Kulshreshtha has done a great job gathering up links to explain what jQuery is all about, why it is a good thing, what people think about it, how you might use it with SharePoint, etc.  From now on when people ask me what they should read to learn about jQuery with SharePoint, this is where I’m going to send them.

I was pinged the other day through LinkedIn by one of my wife’s former colleagues.  Here’s the nut of her request:

… suggested that I contact you to see if you’d be willing to talk with my husband.  He is currently a principal / management consultant at … and is trying to break out of the MC industry to be able to spend more time at home and less time traveling.  … said that you were able to do this and I’d appreciate it if you could give him some tips for breaking free.  He has always been a MC since graduating college and needs guidance on other positions / roles where he can use his skills and feel challenged.  And, of course, still make a good salary. 

Those of you who follow me on this blog, through my MSDN answers, through my jQuery Library for SharePoint Web Services, or via Twitter (@sympmarc) may not realize it, but I do work for a living.  I have my own company called Sympraxis Consulting LLC.  I don’t push it much across those vehicles much because I find it truly annoying when people push too hard. (And here I am pushing a little – I’m not perfekt, you know.)

Here’s the quick perspective that I shared in case anyone else finds it useful:

In my case, it was less “breaking out” and more “changing the rules”.  I worked for some big firms, and loved it much of the time.  Then I went with a very small firm (I was the third hire) and most recently started my own consultancy.

So I still do much the same sort of work, but I do it on my terms.  There are three major benefits that I see:

* I answer to every single employee, but they are all me! (I started Sympraxis Consulting with a partner, but he has moved on to a great new position.)
* I get my own rate. Low overhead, same rates, more $$$ for me and my family.
* I do the work that I choose, whether that means taking something purely for the $$$ or because it’s totally cool work.

With all benefits come some downsides:
* The work is not predictable or steady.  You need to be able to deal with the gaps.
* You have to do everything yourself. That means sales (my least favorite activity, but I’ve gotten more comfortable with it) and managing QuickBooks and all of the paperwork.

I had a question on my recent article over at EndUserSharePoint.com entitled A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): Real World Example – Part 1.  The question was about the SPDisplayRelatedInfo function, and while I was setting things up to see if I had a bug, I found that there were some interesting ways you could use the SPDisplayRelatedInfo function that I hadn’t considered.

I added a Single line of text column to my old standby Sales Opportunities list and called it StateID.  In my EditFormCustom.aspx, I added this call to SPDisplayRelatedInfo:

$().SPServices.SPDisplayRelatedInfo({   
    columnName: "StateID",
    relatedList: "States",
    relatedListColumn: "ID",
    relatedColumns: ["ID", "Title"],
    displayFormat: "table"
});

The States list is one of the lists I use in testing SPCascadeDropdowns, and it has these columns: State (the original Title column) and State Abbreviation. Now, when I typed digits into the StateID column, I got real-time results from the SPDisplayRelatedInfo function as the digits matched the ID of the State item. Cool!

So if I started out with the column empty, I saw:

then when I typed 1:

then when I typed 2:

This also worked if the StateID column was a Number column.  Looking through the code, there was no reason this shouldn’t work, it’s just not the use I had intended.

So then I thought, well what if I wanted to match as I type the State?  I switched the function call to this:

$().SPServices.SPDisplayRelatedInfo({   
    columnName: "StateID",
    relatedList: "States",
    relatedListColumn: "Title",
    relatedColumns: ["ID", "Title", "State_x0020_Abbreviation"],
    displayFormat: "table"
});

Then when I typed Massachusetts, I saw:

Hmm, that can’t be right.  I went and checked the States list, and sure enough, I had some junk test data in there that I had forgotten about.  Even cooler!  The SPDisplayRelatedInfo function essentially acts like an as-you-type reference lookup!

These examples aren’t exactly what you’d be doing in the real world, but think about the situation where you had a product code that could be 1-5 digits or numbers or something where you wanted to let the user type instead of dealing with a dropdown. If you come up with another interesting use, let me know about it.

It’s always nice to find out that code you’ve written is *more* useful than you thought (as opposed to the dreaded less useful situation).

The other day, I tweeted “Am I the only one who thinks that spending a lot of time on #SP2010 right now is premature?” and subsequently wrote my Too Soon for SharePoint 2010? post. I certainly didn’t want to cause trouble with the question, but it’s garnered some interesting responses.

Bjørn Furuknap posted his thoughts on his blog today, and in the Foggy Mountain Breakdown / dueling banjos tradition, I wanted to reply to him.

I agree with Bjørn’s well-said thoughts on Developers and Administrators.  But what should “End Users” be doing while the Developers are developing and the Administrators are administrating?  I would posit that the last thing the Developers and Administrators ought to be doing is, as Bjørn says, letting “end users [be] the last to see these fancy new features”.

No, this is the time to get some of those End Users involved in the process. Without them you’re sitting on a two-legged stool at best; SharePoint shouldn’t even exist without End Users.  Get them involved by doing some pilots of SharePoint 2010 functionality.  Heck, form a SharePoint 2010 committee and use SharePoint 2010 to host a site, a wiki, a blog, whatever it takes to get the End User community up to speed.  Start planting the seeds of what might be.  Do demos, roadshows, create trial sites, get the executives to  see what SharePoint 2010 is all about, etc.  The only way that you’ll have anything to develop on or to administer is if those End Users (as I like to think of them: people) really want SharePoint 2010.  Otherwise, it’s IT just “doing it to them” again.

What ideas do you have to engage End Users now, at this point in the process?  Post ‘em!  I’ll bug Mark Miller over at EndUserSharePoint.com to get on board with this idea, too.  It’ll get the ecosystem revving up more, and more productively, for the long term.

Today I released v0.4.6 of my jQuery Library for SharePoint Web Services.  This version was fun to work on because I’ve got quite a few people out there in the world (California, North Carolina, Sweden) using the library actively, so we were able to work together pretty much real time to get enhancements and bug fixes into the library together.  This was also the first release where I decided to keep a current alpha version posted on Codeplex while I was doing the work.  This was rewarding because there was a real feedback loop going on.  I think this is a better way to go in the future, so watch for more alpha versions you can kick the tires on for me (actually for all of us).

This release has two really nice enhancements:

• SPCascadeDropdowns now works with multi-select child columns. This was the most requested enhancements over the last few months, and to be honest I dragged my feet on it.  The controls that SharePoint uses for multi-select choices are just plain complicated.  There’s also a whole pile of JavaScript which sites behind it all (groupeditempicker.js) that took some time to dig through.  The good news is that I was able to take advantage of those “native” JavaScript functions and write less of my own code.

• Both SPCascadeDropdowns and SPDisplayRelatedInfo now have a new CAMLQuery option which allows you to specify additional filters on the relationshipList.  You specify this as an additional CAML fragment which is then <And>ed with the filters which the library uses to grab the allowable values.  For example, the CAMLQuery option can contain a CAML fragment like:

CAMLQuery: "<Gt><FieldRef Name='ID'/><Value Type='Counter'>1</Value></Gt>"

or

CAMLQuery: "<Eq><FieldRef Name='Status'/><Value Type='Text'>Active</Value></Eq>"

Additionally, the $().SPServices.SPCascadeDropdowns and $().SPServices.SPSPDisplayRelatedInfo functions are now *much* more efficient.  As part of the refactoring I did in v0.4.5, there were some unnecessary Web Services calls happening.  With this efficiency change, there are no unneeded calls, so the dropdowns ought to behave almost as fast as they would without the functions sitting behind them.Of course there are some bug fixes as well.

I tweeted this last night: “Am I the only one who thinks that spending a lot of time on #SP2010 right now is premature?” and I’ve gotten quite a few interesting responses.  I figured I’d start a blog post on this and add in the replies as I get them (see the bottom of this post).  Feel free to comment here as well!

I’m not trying to be a provocateur with the question.  I follow some of the brightest bulbs in SharePoint-land and reading their tweets and blog posts, I hear a lot of furstration about things that don’t work in the SharePoint 2010 Beta.  It’s a beta, so that’s to be expected, and I’m not dissing Microsoft in any way.  I just wonder how much energy should go into SharePoint 2010 right now.

There’s an entire ecosystem around SharePoint, and that ecosystem needs to be well versed in SharePoint 2010 before RTM (Release to Manufacturing, for those not up on Microsoft acronyms).  By that ecosystem, I mean those of us who are consultants, system integrators, trainers, and the like. But should *everyone* be digging deeply into SharePoint 2010? Might we not learn bad habits when we’re forced to come up with workarounds for bugs or missing functionality? Might we not get a bad impression of perfectly good software that isn’t ready yet?

I’m as fascinated with some of the new concepts in SharePoint 2010 as just about anyone.  Some of the new taxonomy ideas are things I’ve been building (or trying to build) into solutions for a good 15 years. The new UI is far spiffier than the MOSS/WSS  3.0 UI (though I’m trying to do my small part to improve the MOSS/WSS 3.0 UI with jQuery Library for SharePoint Web Services). But is it really time?

@jthake: RT @sympmarc: Am I the only one who thinks that spending a lot of time on #SP2010 right now is premature? >> Premature SharePointCulation?

@pndrw: @sympmarc It’s not to early to start learning #SP2010 if you want to be ready go when we get to RTM. There’s lots to learn

@jeffbecraft: RT @sympmarc Am I only one thinks spending time on #SP2010 now is premature? – agree:users; disagree: hosters, consultants, product co’s

@andrewwalmsley: @sympmarc If own time or nothing to do fine, but suspect some are way to early.Maybe 2007 work is drying up,like it did with 2003/7 :-(

@andrewwalmsley: @sympmarc many peeps will be earning money from early ‘heads up’ type information on #sp2010 for their clients and conferences.

@brianroche: @sympmarc there is way too much in the feature set to not spend any time on it. If you want to bet hedge focus on new features only.

@CStahl: @sympmarc #SP2010 – I have to think and focus on my 2007 customers for a long time on, but how can I keep my fingers away from 2010?

Bjørn Furuknap, never the shrinking wallflower, posted an article today about SharePoint Configuration vs. Development.

One of the things that always seems to be missing is the bridge between the two approaches.  I’ve lived on both sides of the wall, and as long as there’s a wall, things fail.  SharePoint is a collaboration platform, yet it’s amazing how infrequently I see people collaborating their way toward a solution.

I’m a HUGE proponent of what usually gets called customization and that’s where I choose to play the game.  That doesn’t mean that I can’t or won’t write "code", it just means that in the majority of cases, I don’t think you need to.  (BTW, I don’t know why it is so, but apparently XSL, JavaScript, jQuery, CSS, etc. aren’t "code".  I think that’s horse pucky.  Code is code is code, and you need to do the right things regardless which one you choose.  For gosh sakes, words are code: look at the trouble people get into using *them* incorrectly.)

So the key, to me, is to understand the portfolio of tools you have at your disposal and which is right for the task at hand.  Don’t use a hammer to drive in a screw.  There’s also a *lot* of middle, fuzzy ground where the right answer might be the one that is going to get you to a solution that works OK in a reasonable amount of time.  So maybe you use DVWPs instead of custom Web Parts (or vice versa) from time to time.  As long as you are actually solving a business requirement, everyone wins.

To paraphrase Rodney King, “Why can’t we all just get along?”

Cross posted from EndUserSharePoint.com…

SPDisplayRelatedInfo is a function in the jQuery Library for SharePoint Web Services that lets you display information which is related to the selection in a dropdown. This can really bring your forms to life for users: rather than just selecting bland text values, you can show them images and links that are related to their choices.

Example

Let’s take a look at a customized edit form (EditForm.aspx copied into EditFormCustom.aspx) for a SharePoint list. In this list, we’re capturing sales opportunities in my favorite demo list. In addition to everything else, we want to capture the System that the customer might want to buy.

Here’s what the form might look like. It’s pretty humdrum (though it does have SPCascadeDropdowns applied to it so that the Country -> Region -> State relationships are enforced, as well as SPLookupAddNew for easy addition of Regions).

If we use the SPDisplayRelatedInfo function, we can spiff up the form quite a bit. Now when we choose a System, we can display an image of it and a link to the Lead Sales Rep:

When the user makes a different selection, the System Image and Lead Sales Rep will change accordingly. Much nicer, IMHO. What you can display in this manner for each column in your list on the form is really only left to your imagination, based on the available column types. You might include a link to a User Manual, for example, or show a list of available inventory at each of your warehouse locations.

Prerequisites

This is one of the places where you’ll be glad if you’ve followed my previous advice to set up reference lists for things like Products, States, and Regions. In this case, I have a list called Systems, which has three columns:

The System column in my Sales Opportunities list is a Lookup column into the Title column of the System list. That gives us a nice, tight relationship between the System value in the Sales Opportunity and the Title of the Systems list.

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.

SPDisplayRelatedInfo currently takes the following options:

$().SPServices.SPDisplayRelatedInfo({
  columnName: "",// The display name of the column in the form
  relatedWebURL: "", // [Optional] The name of the Web (site) which contains the related list
  relatedList: "", // The name of the list which contains the additional information
  relatedListColumn: "", // The internal name of the related column in the related list
  relatedColumns: [], // An array of internal names of related columns to display
  displayFormat: "table", // [Optional] The format to use in displaying the related information. Possible values are: "table", "list".
  headerCSSClass: "ms-vh2",// [Optional] CSS class for the table headers
  rowCSSClass: "ms-vb", // [Optional] CSS class for the table rows
  debug: true // [Optional] If true, show error messages; if false, run silent
});

In the example above, the function call looks like this:

$().SPServices.SPDisplayRelatedInfo({
  columnName: "System",
  relatedList: "Systems",
  relatedListColumn: "Title",
  relatedColumns: ["System_x0020_Image", "Lead_x0020_Sales_x0020_Rep"],
  displayFormat: "list"
});

So I’m asking SPDisplayRelatedInfo to show me the values in the System_x0020_Image and Lead_x0020_Sales_x0020_Rep columns (these are the StaticNames of the list columns as opposed to the DisplayNames) in the Systems list under the System column in my form using the list display format where the System value matches the Title value. I’m just taking the default CSS classes for the example. As you can see, you can pass in any CSS class you’d like to make the SPDisplayRelatedInfo output match your site branding.

The displayFormat takes one of two options:

• “table” displays the matching items much like a standard List View Web Part would, in a table with column headers
• “list” also uses a table, but displays the item(s) in a vertical orientation, like in the example above

How Does It Work?

The SPDisplayRelatedInfo works like this:

• When the function is first called, it attaches an event handler to the dropdown control. The logic here varies a bit depending on what type of dropdown it is.
• When the selected option in the dropdown changes, SPDisplayRelatedInfo calls two Lists Web Service operations:
  • GetList on the relatedList to get information about its columns (fields)
  • GetListItems to get the items where the specified column’s value matches the current selection. Note that there can be multiple items returned; generally displayFormat: “table” makes more sense if you’ll want to display multiple items.
• For each column it’s asked to display, SPDisplayRelatedInfo calls a private function (showColumn) to render the column value based on its type. Most of the normal column types are covered, though locale conversions can’t be done from the client side (yet!).

Conclusion

Quite a few of the early functions I’ve implemented in the library can help you make your forms more interactive and interesting to use. Having worked with data for as long as I have, I know all too well how the GIGO rules can bite you. (Garbage In, Garbage Out, in case you haven’t seen the acronym before.) By utilizing some of the functions like SPDisplayRelatedInfo, you can help your users do a better job adding data into SharePoint lists, and maybe even make it a little bit more fun.

jQuery’s totally cross-browser capable, right?  Well, generally, yes.  However, through no fault of jQuery, Safari and Chrome don’t seem to like the z:row namespace that the SharePoint Lists Web Service GetListItems operation returns.  I found a nice workaround for z:row from Mike Hacker to improve cross-browser compatibility.  I added a check for ItemCount up front so that we don’t try to use the getElementsByTagNameNS function in IE if there have been no rows returned legitimately.

Here’s my function.  I call it with the XMLHttpRequest result wherever I’m using GetListItems to get a usable rowset regardless of the browser.

// Find the rows in an XMLHttpRequest.  This includes a workaround for Safari and Chrome's
// aversion to the z:row namespace.
function getZRows(rXML) {
    var rows;
    var itemCount = $(rXML).find("rs\\:data").attr("ItemCount");
    if (rXML.getElementsByTagName("z:row").length == 0 && itemCount == undefined) {
        rows = rXML.getElementsByTagNameNS('*', 'row');
    } else {
        rows = rXML.getElementsByTagName("z:row");
    }
    return rows;
}

I’ve tested this in IE8, Firefox, Safari, and Chrome on my Windows PC.  It still doesn’t seem to solve the issue on Safari for Mac, but I’m getting there.  This will at least let the functions in v0.5.0 of my jQuery Library for SharePoint Web Services work with all of the main browsers on the Windows side of things.