SPServices’ Load on the Browser for SPGetCurrentUser
Sometimes I catch a tweet out of the corner of my eye and feel a need to comment back and sometimes 140 characters isn’t really enough for me to fulminate with.
http://twitter.com/#!/rolandbouman/status/30614787268280321
Well, yes, but maybe no.
If the only thing you’re loading jQuery and SPServices for is to get the current user’s identity, then it may well be overkill. It’s sort of like using a Dremel tool when all you needed was a Phillips screwdriver. The $().SPServices.SPGetCurrentUser() function certainly makes it easy to get what you need. There are other options on most pages, of course, assuming that you haven’t done too much customization.
For instance, the current user’s name is available in the Welcome control, if it’s there, and you could easily get at it with simple JavaScript rather than using jQuery or SPServices. However, I needed the $().SPServices.SPGetCurrentUser() function to work regardless how much customization has been done, including doing things like removing the Welcome control.
The other point I wanted to make is that the two .js files aren ‘t going over the wire every time the page loads. If you use jQuery and/or SPServices to any degree already, they will be cached in the user’s browser, so there’s no download required after the first (unless the cache is clear one way or another). Yes, the browser still has to load and interpret that 88k (I think that Roland was probably looking at jQuery v1.4.4 and SPServices v0.5.8), but again, it’s a really simple way to get information about the current user. It’s surprisingly hard to find out much more than the user’s name with out the trick that I use in $().SPServices.SPGetCurrentUser() (thanks to Einar Otto Stangvik for the original idea!). One would think that knowing the current user would be a very common requirement client-side, but I was amazed that there wasn’t a CurrentUser Web Service or something once I really started digging into things.
So, yes, using jQuery and SPServices may be overkill just to be able to say “Hi, [yournamehere]”. On the other hand, it works, and it works all the time. As with anything you develop, there’s a requirement to engage brain before coding, so don’t forget to do so on little stuff like this, just like with the big stuff.
Hi!
yup, that’s my tweet. Few comments here:
“For instance, the current user’s name is available in the Welcome control, if it’s there, and you could easily get at it with simple JavaScript rather than using jQuery or SPServices. ”
Been there :) Worked great for me, but not for other users. I don’t know enough about sharepoint to know why it didn’t work for others, but I’m assuming they have the ability to customize their page so that the code I was using couldn’t find that control.
Another consideration is that the welcome control only seems to provide a friendly label for the user. I could’ve lived with that but it would’ve required more work at my end to lookup the real user name.
“The other point I wanted to make is that the two .js files aren ’t going over the wire every time the page loads. If you use jQuery and/or SPServices to any degree already, they will be cached in the user’s browser, so there’s no download required after the first (unless the cache is clear one way or another). ”
Well, kind of. jQuery is used in other places on the site, but not SPServices. And it’s not like this is the only thing on the page – there’s already lots of stuff there and it all adds up.
Another gripe I have with just a plain call to $().SPServices.SPGetCurrentUser() is that it seems to be synchronous. I would rather be called back when the data is there so I can then act and setup my component. I have looked a bit at the code, and I can probably work around that, but it’s just another thing that IMO is making it harder that it should be.
“As with anything you develop, there’s a requirement to engage brain before coding”
I think my brain was working correctly since the code you recommend is working. It is simply my opinion that there should be a less heavy way to achieve this.
One thing I don’t like in particular is the second service call to the userdisp.aspx page. Basically we have to resort to screenshaping a HTML page that seems to be intended to be viewed by end user.
Don’t get me wrong, this is not the fault of the author of the SPGetCurrentUser funcion. But Is it really too much to expect that sharepoint natively offers a proper data service to obtain this information?
Anyway, I appreciate that you took the time to write about this. I can only hope I provided sufficient background as to why I tweeted the message you’re referring to.
Kind regards,
Roland Bouman
Roland:
Most of your points are totally valid. As I said in my post, it sure would be nice if SharePoint let us at this info for the user more easily. However, given that it doesn’t: SPGetCurrentUser(). I had to write the function the way I did (and yes, I’m the author of it) because it was the best option I could come up with.
Even if you are only using jQuery and/or SPServices on other pages, the files will be cached in the browser. So if you are using SPServices on page a.aspx and you need to use it on b.aspx, the .js file won’t download again. So there is that efficiency, at least.
Yes, the call to UserDisp.aspx is synchronous. I did that intentionally because I thought it would address the majority of use cases better. Of course, you have the code so you can customize it anyway you’d like.
Finally, the “engage brain” thing was absolutely not directed at you. What I meant was that taking this “heavy” approach just to get to the current user’s name was probably not a great idea, so I was basically agreeing with you. There’s always more than one way to get things done, and choosing the right one is what requires the thinking. Since you pointed that out, you were clearly doing the thinking I was talking about!
Thanks for the tweet and the additional info. If you ever need anything with respect to SPServices, don’t hesitate to ask.
M.