Apr 17 2012

Making Sense of HTML5 with SharePoint: Hello World

If you’ve been following along with this series, you’ve probably been thinking “Great, but what can I do with HTML5 in SharePoint?” In other words ‘What’s in it for me?” Let’s take a look at a simple example.

First of all, as I mentioned in the last article, we need to make some modifications to the SharePoint master page so that we can take advantage of the HTML5 goodness. It actually gets a bit more complicated than just changing the doctype and a meta tag. Luckily, SharePoint design guru Kyle Schaeffer has done the hard work for us and has published v5, the Responsive HTML5 Master Page for SharePoint 2010. For this article (and probably many following articles), I’m going to use Kyle’s v5 master page to help leapfrog us into HTML5-land. You should be able to follow Kyle’s instructions pretty easily to get v5.master up and running in your environment. Remember that you should only use it in a test environment for this exercise, as there are many reasons why using the v5 master may not be a good idea for your production sites today.

Once you get v5.master installed, the home page of your site ought to look something like this:

image

I’m keeping the look that Kyle’s given us in v5.master as is because it’s distinctive looking and we can easily tell that we’re doing something different. In addition to getting a great HTML5 setup, v5.master also gives you a responsive design layout. As you start to think about how HTML5 and CSS3 might help you to provide SharePoint support for different screen sizes, responsive design is one approach you might consider. (We should really pause here to give Kyle a big hand; this is truly great work!)

So, we’ve got v5.master in place and we can now take advantage of HTML5. (I feel a little like Julia Child when she says “I just happen to have a completed soufflé right here in this other oven.”) In thinking about what a “Hello World” for HTML5 and SharePoint might be, I struggled a little. Regardless what I chose, there had to be some up front work (borrowing Kyle’s v5.master page gets me past that) and putting the words “Hello World” on the page doesn’t show any real HTML5 goodness. I think I’ve settled on something simple enough, yet useful enough, to prove that HTML5 can really make your pages sing, and more easily than using other methods.

One of the things we get with HTML5 is some new attributes for input elements. Input elements are the things we use in HTML to get input from the user. So, for instance, the Title column in any SharePoint list is rendered on the list forms as an input element that looks like this:

<input name="ctl00$m$g_3f366f7e_f974_479a_afcf_552d2de2688e$ctl00$ctl05$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" title="Title" class="ms-long ms-spellcheck-true" id="ctl00_m_g_3f366f7e_f974_479a_afcf_552d2de2688e_ctl00_ctl05_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" type="text" maxLength="255"/>

Once you get past the really long (and ugly) name and id attributes, the input element is pretty simple. It has a title attribute that contains the name of the column (‘Title”), a few CSS classes (“ms-long ms-spellcheck-true”), a type (“text”), and a maxLength (“255″). As far as HTML elements go, it’s about as straightforward as it gets.

Depending on your branding, the input element will render looking something like this. We’ve all seen it before.

Now, we’ve all visited sites where there is a helpful prompt inside the input element that tells us what we should plan to type into it.

It’s a great little mechanism to help a user to understand what they need to do next. We’ve all become very used to it and while we may not notice it after a while, it can lend a great assist. The nice thing about it is that the prompt text disappears when we put our cursor into the input element and it only reappears if we leave the element without typing a value.

SharePoint doesn’t give us this behavior out of the box, but we can make it happen with a little script.

var titleInput = $("input[title='Title']");
var promptText = "Please type a title for this item";

// When we click into the element, remove the prompt text if it is there
titleInput.click(function() {
  if($(this).val() == promptText) $(this).val("");
});

// When we leave the element, replace the prompt text if there is no value
titleInput.blur(function() {
  if($(this).val() == "") $(this).val(promptText);
});

// Set the initial prompt text if there's no value by triggering the blur event
titleInput.blur();

That’s not too complicated, yet it’s more complicated than it seems like it ought to be. I didn’t have an example lying around, so I decided to write it from scratch, which took me about ten minutes. I needed to think about the edge conditions (what if there’s a value but it’s not the promptText?)

So what does HTML5 gain us that makes this easier? Well, there’s a new attribute for the input element called “placeholder”. To get the behavior that I wanted above, I can simply do this:

$("input[title='Title']").prop("placeholder", "Please type a title for this item");

Now you may be saying “Wait a minute. You’re still writing script!” Indeed I am, but it’s only one line of script. The only reason I need to use script at all is that SharePoint doesn’t “know” anything about the placeholder attribute. (I could write managed code to modify the Title column across the board, but that would be tremendous overkill and may not even be what we want.) All the script is doing is adding the placeholder attribute to the input element, and HTML5 takes care of the rest and we get this in the active DOM:

<input name="ctl00$m$g_3f366f7e_f974_479a_afcf_552d2de2688e$ctl00$ctl05$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" title="Title" class="ms-long ms-spellcheck-true" id="ctl00_m_g_3f366f7e_f974_479a_afcf_552d2de2688e_ctl00_ctl05_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" type="text" maxLength="255" placeholder= "Please type a title for this item"/>

Well, HTML5 doesn’t actually do anything, but it tells the browser that it should do the prompt text thing. Unfortunately, Internet Explorer 9 doesn’t support the placeholder attribute yet (check the HTML5 Test again) so I had to run through this little exercise in Firefox.

And there’s the rub again. Since browsers don’t all behave the same yet, we have to consider which HTML5 capabilities we can use. Kyle’s v5.master loads HTML5 Shiv if the browser is IE < 9, but that doesn’t seem to fix it and I didn’t feel like monkeying with it to get it working in IE. In other words, there are still monsters here for those who are not wary.

So, there you go: a “Hello World” exercise, if you will. The real point (in case I didn’t make it well enough) is that HTML5 gives us easier ways to do some common tasks. In this case it’s a simple prompt in an input element, but there are more complex tasks (think playing videos, and more) that HTML5 will also make much easier. Stay tuned for more…

This post also appeared on NothingButSharePoint.com‘s EndUserSharePoint channel on 2012-04-18. Visit the post there to read additional comments.

Permanent link to this article: http://sympmarc.com/2012/04/17/making-sense-of-html5-with-sharepoint-hello-world/

Apr 12 2012

When to Choose SPServices vs. the Client Side Object Model (CSOM)

imageMark Rackley (@MrAckley) and I had a Twonversation with Jeff Jones (@SPJeff) about a month ago about when it is good to use SharePoint’s Client Side Object Model (CSOM) over SPServices. You can see the important bits of that conversation in the image to the right. (Yeah, it’s taken us forever to get this post done. I blame Mark.)

In fact, Mark and I often are asked “When should you use SPServices vs. the CSOM?” Both technologies are script-based, and both allow you to talk to SharePoint through its Web Services. However, there are some important differences to consider when you are deciding which to use,

In this post, Mark and I will try to give you some pros and cons for each. Many of these statements are subjective on purpose; it’s the way the two of us view the two technologies and shows some of the considerations we take into account as we make architectural choices for our clients.

Why You Should Be Using SPServices (says Marc)

SPServices is a jQuery library which I wrote and continue to work on, so I have to admit a strong bias. However, I think there are some clear reasons that you should use it in some cases. It’s not the only answer, but it’s a great tool you can use to solve real business problems.

SPServices exposes a wide range of SharePoint’s Web Services in either SharePoint 2007 or 2010, letting you interact with the Webs, Users and Groups, Permissions, UserProfileService, and Workflow Web Services, and more. This interaction is consistent between SharePoint 2007 and 2010, so there’s no relearning when you upgrade. (Yes, Virginia, there are still a lot of organizations out there running some flavor of SharePoint 2007.)

SPServices supports anonymous access to read from lists, and it works cross-site and cross-domain by simply specifying the webURL in the Web Service operations where it makes sense to do so. Of course, your authentication model has to allow cross-domain access.

The syntax in SPServices is relatively simple and pretty consistent with the way jQuery and other mainstream scripting libraries work these days. All you have to do is pass the Web Service operation you want to call, along with the required parameters in the options. No fuss, no muss. The SOAP Web Services, upon which SPServices is built, return XML and parsing XML with jQuery is old hat for most Web developers. SPServices’ reliance on the jQuery library ensures great cross-browser consistency as well. Most of the code you write using SPServices is going to work exactly the same way regardless of the browser your users have.

Finally, because I continue to develop SPServices – most frequently based on user input – it’s highly likely that I’ll make a new option or function available to meet your needs. I put out new releases of SPServices regularly (there were five releases in the last year) and aim to keep the library evolving and staying current with newer versions of jQuery. Obviously, keeping bugs to a minimum is an ever-present goal. Oh, and it’s free to use on Codeplex, under the MIT License.

Why you should be using the Client Object Model (says Mark)

Yeah.. yeah.. yeah… SPServices is groovy and all and Marc did a great job with it, but if you are using SharePoint 2010 it should NOT be your first choice when it comes to client side development. Why? I’m so glad you asked!

Unless you need anonymous access or cross site access, SPServices is actually a detriment to your SharePoint sustainability. COM is the only way to go.

Like it or not COM is the future and .asmx web services are the past. You need to learn the current technologies and let the outdated stuff go away. Main stream support for SharePoint 2007 ends in October and vNext is just over the horizon. Microsoft has some pretty smart people and I would not be surprised in the least if they addressed the anonymous access issue in SharePoint 15 as well as some of the other limitations.  So, if you don’t use COM and rely on older technologies you may very well find yourself rewriting a lot of code when you could have been ahead of the game.

Additionally COM uses RESTful Web Services and can return your data as JSON which means better performance and less data being passed over the wire. Performance is a huge issue with JavaScript and jQuery so from this standpoint alone COM is the better choice. COM is also structured much more like .NET and has a nicer “feel” to it for the average .NET developer plus it’s more developer friendly (“ows_Title” anyone?).  Lastly, COM is NOT jQuery based. It is written in ECMAScript (JavaScript to the rest of us) so there are no additional libraries or overhead needed. How’s THAT for compatibility?

I think it’s pretty black and white. SPServices is a great tool that I have used quite effectively, but if you are using SharePoint 2010, want better performance, a better development experience, and a technology that will definitely exist in vNext then you have to use the Client Object Model.

Summing it up…

And because I’m typing this, I get to say that Mark is all wrong. No, that’s absolutely NOT the case, All of Mark’s points are valid, but there isn’t a one-size-fits-all answer to everything. To help you decide which directions to take for your own organization, we’ve compiled this list of pros and cons for each option. Do you have other ideas for pros and cons? If so, please post the here in the comments or on Mark’s post on his blog.

This post also appeared on NothingButSharePoint.com‘s EndUserSharePoint channel on 2012-04-25. Visit the post there to read additional comments.

SPServices

Pros

  • A wide range of SharePoint functionality is exposed with the SOAP Web Services, much of which is not available in CSOM
  • Allows anonymous access (assuming it is enabled for the underlying objects)
  • Works cross-site and cross-domain, assuming that the authentication model you are using allows it
  • Simpler syntax than the CSOM. Simply pass the required parameters to the Web Service operation, e.g., GetListItems
  • Built on top of jQuery, which is very good at ensuring cross-browser compatibility
  • Regularly updated and refined to be compatible with new versions of jQuery and to add new functionality based on user input
  • Works identically in SharePoint 2007 and 2010 (where the same Web Services exist – see chart)

Cons

  • The SOAP Web Services which SPServices wraps is “old” technology which only returns XML
  • Because the SOAP Web Services are older technology, they may not be supported as long as CSOM

CSOM

Pros

  • Provides access to the “modern” RESTFul Web Services which return JSON or XML based upon your need
  • Coding patterns mirror .NET, which may make more sense to .NET developers

Cons

  • No anonymous access
  • No cross-site or cross-domain capabilities
  • Complicated syntax which mirrors .NET coding patterns, which may make less sense to Web developers
  • Have to create your own success and failure methods

Permanent link to this article: http://sympmarc.com/2012/04/12/when-to-choose-spservices-vs-the-client-side-object-model-csom/

Apr 04 2012

Customizing the Display of a SharePoint 2010 Blog

I’ve changed pages countless times in SharePoint Designer, but this case, where I wanted to make a relatively small change to the home page of a Blog site, proved especially onerous.

In most cases, overriding the default XSL is as simply as editing what’s there and saving your changes.

It would seem that the team that works on blogs doesn’t chat with the rest of the product group, because blogs work differently. Blog pages use an XSL file called blog.xsl, which live in the _layouts folder on the Web Front Ends (WFEs).

On the home page of a blog site (default.aspx), there are several XLV Web Parts, but the main one is the one which displays the most recent posts. All I wanted to do in this case was display a different column instead of Created By (@Author) . Because in many organizations someone different that the author is the person who types the post, we had added a Written By column to the Posts list. The logic was simple: if the Written By column had a value, show it, otherwise show the Created By column as usual.

I wanted to keep the XLV Web Part in place in case we needed to work with it in the future, plus the markup it emits is a bit crufty and I didn’t want to have to replicate it all with a custom DVWP. (In retrospect, this *may* have been easier.)

It should have been pretty easy to make the change, but I went down some rat holes. I don’t want *you* to go down those rat holes, so here’s what ended up working.

Open the page in SharePoint Designer, position your cursor on the XLV Web Part which displays the posts and in the List View Tools section of the ribbon, choose Customize XSLT / Customize Entire View.

image

This pulls the XSL from blog.xsl into the page, in theory so that we can customize it. However, don’t go down that path; there be monsters. Instead, find the line:

<xsl:include href="/_layouts/xsl/blog.xsl"/>

and Ctrl-Click on the href link to the blog.xsl file. This will open the blog.xsl file in a different SharePoint Designer window for the root of the Site Collection. This is handy, because you now want to save a copy of blog.xsl in a Document Library in the root site of the Site Collection. I usually create a Document Library called XSL anyway to hold frequently-used XSL templates, like the ones I have in my SPXSLT Codeplex Project. I named my copy BlogWrittenBy.xsl.

Close the default.aspx page you opened in the blog site now WITHOUT saving it. Remember? Monsters. Open it again. See, no monsters.

Since we had added a new custom column called Written By, I needed to add it to the ViewFields section so that the XLV Web Part would retrieve values for it:

<ViewFields>
  <FieldRef Name="Title"/>
  <FieldRef Name="Body"/>
  <FieldRef Name="Author"/>
  <FieldRef Name="PostedByWithDate"/>
  <FieldRef Name="CategoryWithLink"/>
  <FieldRef Name="Permalink"/>
  <FieldRef Name="EmailPostLink"/>
  <FieldRef Name="NumCommentsWithLink"/>
  <FieldRef Name="PublishedDate"/>
  <FieldRef Name="PostCategory"/>
  <FieldRef Name="Written_x0020_By"/>
</ViewFields>

Then I saved the file. Yes, that customizes (or unghosts) the file. I’m OK with that.

Back to the BlogWrittenBy.xsl file I saved above. I found the section of the XSL where Created By (@Author) is emitted:

<xsl:when test="@Name='Author'"><span class="ms-postfootercolor"><xsl:value-of select="'by '"/></span><xsl:text disable-output-escaping="yes" ddwrt:nbsp-preserve="yes">&amp;nbsp;</xsl:text><xsl:value-of select="$thisNode/@Author.span" disable-output-escaping="yes" /></xsl:when>

and replaced it with this:

<xsl:when test="@Name='Author'">
  <xsl:variable name="ShowPerson">
    <xsl:choose>
      <xsl:when test="string-length($thisNode/@Written_x0020_By.id) &gt; 0">
        <xsl:value-of select="$thisNode/@Written_x0020_By.span" disable-output-escaping="yes"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$thisNode/@Author.span" disable-output-escaping="yes"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:variable>
  <span class="ms-postfootercolor"><xsl:value-of select="$thisNode/../@resource.wss.ByPrefix"/></span><xsl:text disable-output-escaping="yes" ddwrt:nbsp-preserve="yes">&amp;nbsp;</xsl:text><xsl:value-of select="$ShowPerson" disable-output-escaping="yes" />
</xsl:when>

This added the conditional logic we wanted.

Next, off to the browser, where I opened the page for editing. In the Tool Pane for the List View Web Part which shows the blog posts, I went to the Miscellaneous section and added a link to my XSL file in the Xsl Link field. In my case, since it was stored in the root of my Site Collection, the link was /XSL/BlogWrittenBy.xsl.

Then I saved the change and voila! Exactly what I wanted.

There are other ways to accomplish what I did here with a deployable feature and managed code, etc. In this case, it was a small farm with only a production environment and a single blog where we wanted to make the change. All you enterprise types just gasped, but this is the reality in many organizations.

Obviously it wasn’t all as simple as what I outline above. Here are some of the things I found:

  • If I edited the XSL in SharePoint Designer (after the Customize Entire View step), my changes worked great in SharePoint Designer,. However, when I went to the browser, I saw the page the same way it had looked before. I believe this is because the blog.xsl file was pulled in anyway, and no amount of jiggling things could get me past that.
  • If I tried to add the XSLLink in SharePoint Designer, which ought to work, it always stripped off the leading / in the link to the XSL file. This meant that the link was invalid and blog.xsl was used again.
  • The sequence I ran through above seems to be the only reliable way to make this work. It’s pretty quick (after 47 tries) and I did it twice as I was writing this. Of course, I had a copy of the original default.aspx file to work with. Never edit the default files without making a copy.

Here are two threads from the MSDN Forums that helped a bit. I didn’t have any luck with the ddwrt:ghost="hide" approach.

http://social.technet.microsoft.com/Forums/en-ZA/sharepoint2010customization/thread/669d7d94-45ad-4fa0-8fe9-069d44ba07fa

http://social.technet.microsoft.com/Forums/en-ZA/sharepoint2010customization/thread/9e5862b2-5271-47b8-8c9c-7742b7af55eb

Permanent link to this article: http://sympmarc.com/2012/04/04/customizing-the-display-of-a-sharepoint-2010-blog/

Apr 02 2012

Making Sense of HTML5 with SharePoint: Browser Capabilities

In my last article I talked about what HTML5 is and that it will help us get to a more  “Semantic Web”, but I didn’t explain what the W3C standards really mean. Partly that’s because the process is long and drawn out and murky at best. When I talk about the HTML5 recommendations and standards, maybe I should put “recommendations” and “standards” in bold, flashing text. The word recommendation is closer to the mark. Take that and the fact that the HTML5 standards are in draft mode, and there’s a lot of loosey-goosy-ness to the whole thing. I’ve seen quite a few people saying that the HTML5 standard will be finalized in 2022, and they aren’t really joking. That’s about par for the course if we look at the life cycles of past HTML standards.

What all that means for browser capabilities is that they are basically all over the place. While each browser team wants to support HTML5 (at least if they want to be as cool as the other kids), they each have different priorities and interpretations of the standard.

This post also appeared on NothingButSharePoint.com‘s EndUserSharePoint channel on 2012-04-03. Visit the post there to read additional comments.

The HTML5 Test

One good way to understand what this all adds up to is to look at a site that I found called The HTML5 Test. It’s not the only site out there that will tell you how your browser stacks up, but I like the way it gives an overall score and then breaks things out into easy to understand sections.

Because of my consulting work, and even more because of my SPServices development work, I have most of the major browsers on my laptop. Here’s how the versions of each browser I have stack up on The HTML5 Test:

Internet Explorer 9
Version: 9.0.8112.16421
image
Firefox 11
Version 11.0
image
Safari 5
Version 5.1.5 (7534.55.3)
image
Chrome 18
Version 18.0.1025.142 m
image
Opera 11
Version 11.62 Build 1347
image

While it may seem just like a gratuitous way to add a bunch of images to this article to make it longer, I thought it was interesting enough to include the details. As you can see, the scores are all over the place, and none of them are all that close to the maximum of 475. (If you have an eye for this sort of thing, you’ll note that even these snapshot images don’t look exactly the same, though they should.) Worst of all, our dear old friend IE9 scores the lowest. If you dig into the details of the scores, you’ll see that the variations are even harder to think through.

What this tells us is the we have to be very careful to understand what our browser base is for SharePoint if we want to take advantage of the goodness that HTML5 provides. (This is true of any so-called “front end” development that you do – you simply *must* know your browser targets and have good strategies to deal with them all.) I haven’t been able to find any typical browser distribution statistics for SharePoint on the Interwebs, but SharePoint itself can tell you what browsers are visiting your installation if you look at the Web Analytics statistics.

If you are lucky enough to be building your solutions in an organization where the supported browser base is proscriptive (e.g., everyone *must* use IE8 or Firefox 11 or something) then your job may be a little bit easier. However, as the BYOD movement takes hold, even that luxury is eroding. On the other hand, if you’re developing for an Internet site, then all bets are off. You’ll see everything from IE6 to Netscape to Opera to IE10 Beta and back again.

SharePoint and Browser Support

SharePoint 2010 itself, while it can be used with just about any browser, is really primed for Internet Explorer. If you look at the out of the box v4.master page, you’ll find several strong indications of this. In fact, these are the two first things you’ll need to change to start using HTML5 in SharePoint.

First, there’s the DOCTYPE.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

This doctype tells browsers which standard to adhere to. In this case, it’s the XHTML 1.0 Strict standard. This setting precludes us from getting any HTML5 goodness. To enable HTML5, it’s a simple matter of changing the doctype to the simpler:

<!DOCTYPE html>

Next, the v4.master page has a meta tag in the header which forces Internet Explorer into IE8 mode:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

To allow IE9 to flex the HTML5 muscles that it *does* have, you can change this to:

<meta http-equiv="X-UA-Compatible" content="IE=9"/>

So Now What?

As I noted above, even IE9 doesn’t score all that well on The HTML5 Test. So how can we try to take advantage of HTML5 until Internet Explorer and all of the other browsers catch up to the moving target that is the HTML5 standard?

Well, luckily, there are people out there who understand these issues well and they have written some things that can help.The most well-known option is something called Modernizr.

Modernizr is an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.

Modernizer falls into the class of software known as “shims”. Shims let us use functionality which isn’t there for us yet by mimicking that functionality in a different way or otherwise filling in the gaps. Or, in geekspeak from Wikipedia:

In computer programming, a shim (from shim) or shiv is a small library that transparently intercepts an API and changes the parameters passed, handles the operation itself, or redirects the operation elsewhere. Shims typically come about when the behavior of an API changes, thereby causing compatibility issues for older applications which still rely on the older functionality. In such cases, the older API can still be supported by a thin compatibility layer on top of the newer code. Shims can also be used for running programs on different software platforms than they were developed for.

Once the browsers catch up, the shim won’t need to do as much and eventually we’ll be able to get rid of it. (Don’t hold your breath – 2022 is a long way off.)

You can reference Modernizr in your master page to take advantage of HTML5 functionality that the browsers doesn’t yet provide. It’s not a silver bullet, of course. You still need to understand your target browser base and think about how you are going to use the new standards to get the best results. Knowing where in all that the shim is going to support you is key.

I’m not going to go into anything specific that Modernizr can help with in this article, but I will touch upon useful capabilities it provides as we see how we can use HTML5 in SharePoint as we go along.

Don’t worry; cool demo stuff is coming. I just think that we should understand the basics first.

Resources

Permanent link to this article: http://sympmarc.com/2012/04/02/making-sense-of-html5-with-sharepoint-browser-capabilities/

Mar 29 2012

Cool SPServices Developments Today

A couple of cool things happened today with SPServices that I thought I’d capture in a post.

First, I saw a couple of tweets this morning from Ryan Kirkman (@ryan_kirkman). Ryan runs a CDN for JavaScript solutions called cdnjs.

CDNJS was started in January 2011 as an attempt to speed up the web. It was hosted on Amazon until CloudFlare took over hosting using their own CDN in June 2011.

At the moment the site itself is managed by two passionate web-developers from Australia.   Feel free to get in contact with us at anytime.

@ @ Hi guys, I added jquery.SPServices to cdnjs for you: http://t.co/ivxSl2fQ (file link is here: http://t.co/5z7h1sIy)
@ryan_kirkman
Ryan Kirkman

I’ve had suggestions from quite a few people over the last six months or so to get SPServices up on cdnjs so that they could reference it there rather than host it locally. I’ve wanted to do it, but each time I look at the fact that I need to learn how to use git to do it, I’ve lost steam. I really do want to learn how to use git, and I will (Codeplex just made it available as one of the source control options), but I haven’t yet. Ryan saw me tweet about that yesterday to Simon (@binaryjam) and posted the latest version of SPServices on cdnjs for us. Hooray! (But I still need to learn git.) If you’d like to use SPServices v0.7.1a from a CDN, you can do so by referencing it at the URL:

http://cdnjs.cloudflare.com/ajax/libs/jquery.SPServices/0.7.1a/jquery.SPServices-0.7.1a.min.js

I’ll figure out how to get some of the other recent versions up there as well.

<UPDATE date=”2012-03-30″>

Josh McCarty (@joshmcrty) was kind enough to add some of the older versions of SPServices to cndjs as well. Take a look at his pull request to see the list. If you’d like any other versions, please let me know.

</UPDATE>

The second thing came from a guy named Ben Tedder (@bentedder) who has been writing a lot of great posts about SPServices on his blog.

A hand-drawn intro to jQuery SPServices http://t.co/QZgrcxVy
@bentedder
bentedder

I haven’t had the pleasure to meet Ben (his listing on Twitter puts him in Beijing, China) but I’ve appreciated his posts. Today he did something unique, at least for SPServices. Here’s his “Hand-drawn intro to jQuery and SPServices“. I think it’s pretty cool.

Permanent link to this article: http://sympmarc.com/2012/03/29/cool-spservices-developments-today/

Page 20 of 161« First...10...1819202122...304050...Last »
%d bloggers like this: