I'm trying to understang how AJAX and Sharepoint play together

Question

I'm about to embark on a project whose goal is to take a Sharepoint wiki of documentation, and add an index as the left nav (right now, there's only search). As users click on an index item, the right hand side populates with the document from sharepoint. Sounds like a relatively simple AJAX job, but since SharePoint is new for me, I'm not sure I even know the questions to ask.

To start, I'm wondering if my AJAX components (JS & associated CSS/HTML) can live on a separate webserver, or if it needs to run on the same server where Sharepoint is installed? Our IT department tries to isolate applications from data whenever possible, and this has been classified as "data", not an application. What is a best-practices strategy for where CSS, JS, and HTML lives--relative to SharePoint's home directory?

Second, in hunting down API documentation, I'm found MSDN's resources to be quite confusing. There's a lot of contradictions and a lot of user comments about poor/outdated documentation. Does anyone have any recommendations for some good resources for AJAX and Sharepoint, inlcuding code sample libraries? I tend to work best when I can explore code and experiment with it to understand what any why it does what it does.

Thanks

Answer 1

I've done ajax a few different ways.

When deving webparts I usually try to use the ICallbackEventhandler (http://msdn.microsoft.com/en-us/library/system.web.ui.icallbackeventhandler.aspx), especially when creating webparts that need ajax.

I've also had a scenario when I used an update panel (http://msdn.microsoft.com/en-us/library/system.web.ui.updatepanel.aspx) to dynamically create a server side control and render it's content. This was a webpart that had different tabs on it and each tab would render a webpart. For performance reasons, I had each tab ajax load it's content using an UpdatePanel. This was needed because an updatepanel goes through the full page lifecycle which a webpart needs in order to render and the ICallbackEventHandlers doesn't.

More recently I used jQuery and webservices to dynamically fill in content in the background to reduce page load time with the appearance of having everything already loaded on the page. As in when the mouse was hovered over a button, I would ajax load that content so that by the time they clicked on the button the content was already loaded.

SharePoint is still just an advanced ASP.NET website, if you can think about it that way, it can take you far in understanding what can be implemented in SharePoint.

Answer 2

SharePoint works great with AJAX. Two of the great improvements for SharePoint 2010 was Client Side Object Model and REST interface which makes JavaScript development against SharePoint a lot easier that using the old Web Services.

Another great option which makes a the Web Services usable and provides a lot of great functionality (and good documentation) is the SPServices jQuery library.

In my opinion the best way to develop AJAX for SharePoint are either custom pages or Visual WebParts as it allows me to use Visual Studio with TFS for my development. But as your IT Department has decided that your app is data the main option are:

• Put the JavaScript into Content Editor WebPart, easy with small pieces but hard to keep structured as your project grows.
• Put the JavaScript into files stored in a document library, can be annoying to work with, but best if you want to be able to reuse script files. You can open the library in Explorer view to make it easy to drag/drop files.
• Edit the JavaScript in pages created using SharePoint designer, again best for small pieces a little harder write/save/test cycle, but a bit better protected against endusers that Content Editor WebPart.

SharePoint doesn't care if the javascript is from another server, but unless you can get the IT department to do some magic with the routing of requests you'll very easily run into problems with the Browser rejecting Cross Site Scripting as you'll have problems loading your scripts from the same domain.

Answer 3

I largely agree with Per on this one. (+1 Per)

Loading JS from another server, especially when using HTTPS for SharePoint causes warnings in IE about loading unsecured/untrusted resources (I can't exactly remember the message). You can load JQuery (for example) from a CDN just fine but this is the problem we had when doing this. Also from memory, I think that Firefox and Chrome take a less paranoid view of the world and just accept it.

As for where to put your JS, Per's option 1 will give you some headaches with deployment and version control. Option 2 is my preference for non-infrastructure JS (deploying to a library). Infrastructure (eg. JQuery) for me lives in LAYOUTS as we use it across web applications. Deployment happens through WSPs as it usually accompanies other components. These JS files are version controlled along with everything else. Option 3 has similar pros and cons to option 1 on top of what Per said.