The SharePoint Hillbilly

Online Quiz: Is jQuery a valid option for your project?

Mark Rackley — Tue, 13 Dec 2011 03:20:49 GMT

Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2011/12/12/online-quiz-is-jquery-a-valid-option-for-your-project.aspx

So, to step back up on my soapbox for a quick moment. The buzz and the noise around jQuery and Client Side development in general is growing and at a fairly rapid pace. This of course is good and bad. It’s good because our applications are becoming more and more user friendly and the visual appeal is increasing exponentially a well. Plus, as developers, we get to develop some pretty awesome functionality that before we would have had to crack open Visual Studio to get the same results. It’s definitely an exciting time.

However, with this mass adoption comes a lot of headaches. Users are copying and pasting random scripts they find online (and not telling their administrators and developers about it). Developers are writing bad JavaScript and jQuery because they simply don’t know any better. In addition, many less-than-well-rounded developers are making jQuery their “go-to” language because that’s what they know, and hey “it works” so, “why not”? right?

Unfortunately, with jQuery it also becomes exponentially easier to break a page, cause bad performance, or in some instances bring down your farm. Add to that new technologies like Windows 8 and more and more applications moving to the cloud, client side development is only going to continue to grow. It becomes more critical every day that developers make the right decision as to HOW and WHEN they should be using tools like jQuery.

To help you guys make this decision for you projects I implemented the little quiz below. If I did my job right and weighted the scores properly it should give you a fairly accurate response and let you know if jQuery is even an option for what you are considering for your environment. And hey, it was fun to write, so even if the scoring is way off it was a nice break from my normal work routine.

Go ahead, give it a try. If you have suggestions for more questions or for changing the weighting to be more accurate, I’d love the feedback. As always, thanks for stopping by!

Question	Yes	No
Do you know JavaScript and CSS? Do you have the ability to debug your scripts and understand what they are doing? Are you NOT just copying and pasting someone else’s script you found floating around out there?
Do you need to manipulate large amounts of data? Do you need to scrape data from tables to build charts/graphs or make web service (client object model) calls to retrieve many rows of data (more than a couple hundred) and iterate through them.
Do you have a plan to maintain and deploy your scripts. Do you know where your scripts are going to live and how you are going to reference them? Do you know how you plan to update the scripts and test these updates?
Do you have to ability to deploy custom solutions (.WSP files). jQuery is a great too when you simply don’t have another choice. In SharePoint 2007 you have to have access to the server to deploy custom code, however in SharePoint 2010 you do get access to Sandbox Solutions which are great option.
Do you have Visual Studio? One of the great things about JavaScript/jQuery is that all you really need is a document library, a CEWP, and notepad.
Does the success of your project rely on quickly modifying and deploying functionality per endless user requests.. I mean.. These guys can't make up their mind.. One day they want blue text, five minutes later they want it red… oh.. And while you're at it can you make that button two pixels larger... really??
Is performance a concern? Is it okay that your page takes 8 seconds to load because the client is doing business calculations that may be done more quickly and efficiently on the server side if this were managed code?
Is this an external facing site where you have no control over what type of computer or browser the user will be using? jQuery is executed on the client computer and if you are using jQuery on an external facing site, you have no control over which browser a user is using or how old and slow it may be. Make sure to tell your external apps in every configuration known to man… twice…
Is visual appeal and usability a major concern? Do the users like animations, or changing colors, or instant feedback while clicking around? Do you get “oohs” and “ahhs” for the simple stylish things that are secretly the easiest part of the application?
Could you develop the same functionality in .NET more quickly and efficiently? Again, just because you know jQuery, doesn’t mean you should use it for everything.
Are you willing to take responsibility for the script you deploy to your site? End users should not be copying and pasting scripts they find online and then whining to their IT department when it doesn’t work right or effectively. If you are going to use jQuery, take responsibility for problems it may cause.
Have you thoroughly tested the scripts on systems similar to the ones your users will be using? Just because it works on your computer, doesn’t mean every user will have a pleasant experience. Take the effort to test and test extensively. Again, for external sites, test, test, test, test, and then test… followed by testing…

Should you be using jQuery?

Answer the questions to calculate your score.
Calculated Score:

SharePoint Saturday Denver–Wrap Up and Slide Decks

Mark Rackley — Sun, 04 Dec 2011 22:31:02 GMT

Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2011/12/04/sharepoint-saturday-denverndashwrap-up-and-slide-decks.aspx

So, SharePoint Saturday Denver kicked off a very busy few weeks for me and I’m just now getting around to posting my slide deck from the event. I know, I’m a slacker. Feel free to berate me.

In case you haven’t heard, Clayton Cobb (@warrtalon), Toby Mai (@grumpytech) and crew did an amazing job putting together a solid two day event. The first day was a “paid” day and the second day was free for all attendees. I REALLY like this format as both a speaker and an organizer. It really enhanced the conference without taking away the spirit of SharePoint Saturday. Again, GREAT job by all those who organized and helped out.

On Friday I spoke about my love/hate relationship with jQuery in sort of a hybrid session between my previous jQuery sessions and my SharePoint Conference session I did with Eric Harlan.

The more I speak about jQuery and the more I use jQuery and the more I hear about how other people are using jQuery the more I know that this session is critical and that people need to learn the right way to do jQuery. There are too many people drinking the jQuery kool-aid and using it as their go-to tool when in some instances it shouldn’t even be an option. jQuery is a GREAT tool, and client side development is only going to grow in the future. So, people MUST learn to use it and use correctly. *steps off of soapbox*

Anyway, for day 2 I decided to finally update the first session I ever presented “Wrapping Your Head Around the SharePoint Beast”. This thing was due for a rewrite. I still present this session as the session I wish *I* would have seen when SharePoint was dumped in my lap and I hope you guys that attended got something useful out of it.

I had great crowds in both sessions and met a lot of great people. I’m definitely looking forward to the next SharePoint Saturday Denver.

Next up for me is SharePoint Saturday Kansas City on December 10th where I will again be presenting both of these sessions. Hope to see you guys there!

Rookie Mistakes–ServerRelativeUrl & SPContext

Mark Rackley — Sun, 06 Nov 2011 18:28:23 GMT

Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2011/11/06/rookie-mistakesndashserverrelativeurl-amp-spcontext.aspx

So, I love how hindsight is 20/20. I love when I carefully (okay sorta carefully) write code, step through it in the debugger, check values, properly catch errors and dispose of objects and you STILL have some stupid error that humbles me a little. Yeah, welcome to my world. In fact I almost didn’t post this blog because I felt pretty foolish, but I figured if I made the mistake maybe someone else did too and I’m all about looking like an idiot if it helps someone else succeed.

This is also the part of my blog where I encourage everyone to start a blog and write about their “duh” moments. You never know who might benefit from a little common sense. I know I could generally use a healthy dose of it.

What was I trying to accomplish?

Just to give you some backstory and my blog post more verbiage, let me help you understand what I was trying to do. Maybe even a few of you guru’s out there will say “Why the heck didn’t you just do ‘x’??”.

I had the requirement to allow a user to take a SharePoint site located at http://websiteurl/SiteToMove and move it under some other site in the current site collection’s hierarchy such as: http://websiteurl/ParentSite1/SiteToMove or http://websiteurl/ParentSite1/SubSite2/SiteToMove.

I could go into more backstory about why I needed to do this and why other alternatives would not work for us, but it really isn’t germane to the rest of the post. So, let’s assume for the sake of argument there was a good reason, and the other options for achieving the same functionality were not desirable.

How to ‘move’ a SharePoint site?

So, your first question may have been the same as mine, how do you take a SharePoint Site and move it underneath another site? Sounds kind of hairy doesn’t it? I did a few Google.. I mean Bing searches and didn’t find anything very helpful. What are the magic search terms here to get the answer? Well, I went to my second option, which was posting the question on Twitter, and wouldn’t you know it; within 10 minutes I had responses from @Jimmywim, @CraigToThePoint, and of all people @toddklindt (whom I’m convinced is a closet developer) about how this is done.

And when I heard the solution I wanted to facepalm… could it really be that simple? I mean, can anything Todd Klindt say really be trusted? (Yes and Yes by the way).

Apparently all you have to do “move” a site in this instance (same Site Collection) is update the SPWeb.ServerRelativeURL for the site in questions. That’s it… It sounded so easy I was skeptical, but I tried it out on a small scale and it worked brilliantly! I was a happy camper. Thanks again guys…

How I implemented it

Now I needed to give a user an intuitive way to “move” their site.. So, I created the following process:

User browses to their site
Using a custom web part, user selects which site in the hierarchy of sites is the “parent” site of their site.
The user site’s ServerRelativeUrl is updated with new Path using the path of the “parent” site.

Sounds simple enough? Doesn’t it? And it worked… except that after the web part came back from the PostBack it was throwing an error saying my site didn’t exist, but the site did exist, and it was even updated to the correct path.

Can you guess what I did wrong? Here’s my genius code:

                SPContext.Current.Web.ServerRelativeUrl = newRelativeUrl;
                SPContext.Current.Web.Update();

Now do you see it? I should not have modified the Web object in SPContext. The web part needs SPContext on the reload of the page after it comes back from the postback, and since I modified SPContext it was not able to reload the page properly.

When I instantiated my own SPWeb object and updated THAT object’s ServerRelateiveUrl (and properly disposed of the object), everything worked fine and all was right with the world.

Moral of the story

So, moral of the story, and my “duh” moment is be careful updating SPSite and SPWeb objects within SPContext. In fact, you should probably instantiate new objects when updating SPWeb, SPSite, and other collections from SPContext. I know I learned my lesson and will be more careful in the future.

I love making rookie mistakes. On the bright side, at least it wasn’t another jQuery post.