Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

SharePoint 2007 and the Thin .NET 3.5 Development Model : Page 2

Merge your SharePoint development with WCF to work around some of SharePoint 2007's problems and enable the thin .NET development model.


advertisement
The New .NET 3.5 SharePoint Development Story
The thin .NET 3.5 development story lets you treat SharePoint 2007 as a true application platform. Rather than developing code inside SharePoint 2007, you develop it externally—as libraries, which are easier to test and debug. This external development method also lets you deploy functionality incrementally, as you write the WCF back end, or the Silverlight, AJAX, JavaScript, or some other front end. Again, here's an example.

The thin .NET 3.5 development model greatly increases your productivity.
Suppose you have a SharePoint site with a number of song titles loaded in a custom content type. Now, you could easily create a custom search scope to limit the results to that custom content type. You can view an example of running search programmatically on SharePoint 2007 here. You can then easily craft up the search functionality as a WCF endpoint and deploy it cleanly as a solution, as shown here.

After your WCF service is deployed and available as a part of the SharePoint platform, you can then use it in multiple front ends. I will discuss three here, but trust me; there are many, many other possibilities. But these three should get you excited enough—for now!

Using WCF in Silverlight
 
Figure 1. Custom Silverlight Application in SharePoint: Here's an example that shows a custom Silverlight application running in a SharePoint page.
Your WCF application can be consumed directly inside a Silverlight application. You can create a WCF proxy for a WCF service that uses basicHttpBinding in Silverlight as demonstrated here. Then you can deploy a Silverlight .XAP application to a document library using the tag in CAML, and download it in a Silverlight-enabled SharePoint web site. Figure 1 illustrates a simple Silverlight application running inside SharePoint that queries song data using a WCF endpoint exposed on basicHttpBinding.

Using WCF with AJAX
After you've written and deployed your service library, and assuming that you decorated it by its own namespace, you can simply expose an endpoint that uses webHttpBinding and an endpoint behavior called enableWebScript. This allows the WCF runtime to expose your C# or VB WCF service functionality through automatically-generated JavaScript.

For example, if your WCF contract looked like this:

[ServiceContract(Namespace = "Winsmarts")] public interface ISongQuery { [OperationContract] [WebGet] List<BO.Song> GetSongs(string containsText); }

You could expose the service's functionality in JavaScript as shown below:

function GetResults() { var resultsDiv = $get("results"); resultsDiv.innerHTML = "Fetching results .. "; var proxy = new Winsmarts.ISongQuery(); proxy.GetSongs($get("containsText").value, onSuccess, onFail); }

As the preceding code shows, the namespace becomes a JavaScript namespace, and then you can simply instantiate a proxy inside JavaScript.

To use the code, you add a ScriptReference to the WCF endpoint, shown below:



<asp:ScriptManager ID="ScriptManager1" runat="server"> <Services> <asp:ServiceReference Path="SongService.svc" /> </Services> </asp:ScriptManager>

Just like all AJAX-enabled endpoints, the preceding code requires you to host the WCF endpoint in the same domain as the JavaScript code.

Using WCF with the AJAX Control Toolkit
The AJAX Control Toolkit is a wonderful set of controls. You can view the toolkit running here. The good news is that with WCF, it's quite easy to use all these tools inside SharePoint. All you have to do is create a WCF service reference that looks similar to the one shown below:

[ServiceContract(Namespace = "winsmarts")] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] public class WCFEndPointClass { [OperationContract] public string[] WCFQueryMethod( string prefixText, int count) { // Implementation goes here } }

Expose the service reference over a WCF endpoint that uses webHttpBinding and the endpoint behavior enableWebScript. After doing that, you can use any of the Ajax Control Toolkit controls. For example, the following code uses the AutoCompleteExtender control:

<ajaxToolkit:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server" /> <asp:TextBox ID="prefixText" runat="server" Width="280"/> <ajaxToolkit:AutoCompleteExtender runat="server" TargetControlID="prefixText" ServicePath="/_vti_bin/_wcf/WCFEndPointClass/ WCFEndPointClass.svc" ServiceMethod="WCFQueryMethod" ... other properties> </ajaxToolkit:AutoCompleteExtender>

You can see an example of the AutoCompleteExtender being used on the NewItem.aspx of a list in Figure 2.

 
Figure 2. Using Ajax Control Toolkit Controls: Here's an example of using the AutoCompleteExtender control.
Yes, you read that right. The example uses the AutoCompleteExtender inside the autogenerated NewItem.aspx page for a list. The autogenerated page is usually a pain to customize. You can do some limited customization through the SharePoint designer, but how exactly do you get rich functionality as shown above? Do you use InfoPath Forms and craft a custom content type that insists on using those custom forms?

First of all, InfoPath 2007 browser-based forms don't give you AJAX Control Toolkit-like features. InfoPath, while quite powerful and useful, isn't known for its easy extensibility when it comes to its controls, and frankly, the above solution just works better.

Wrapping Up
I have discovered the light. If there was anything wrong with SharePoint 2007, it was the unwieldy development experience. You had to:
  • Work on a machine that had SharePoint installed.
  • Debug frequently inside the SharePoint context.
  • Attach and detach w3wp.exe frequently, and if you detached the wrong one, even when you did attach to the correct one, breakpoints would mysteriously not get hit, because the DLL in the GAC was different from the DLL that IIS was using, which was different from the newly-compiled DLL.
Moreover, developers typically did all this inside a virtualized environment which, half the time, involved either staring at frozen Visual Studio instances or at the SharePoint spinner.

You'll find that the thin .NET development model fixes all these problems. You've seen only a brief introduction and a couple of examples so far, but you'll see more in three subsequent articles, which take each of the scenarios described here, and explain, in depth, exactly how to implement them.



Sahil Malik Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant and trainer, and a well-rounded overweight geek. He has a passion for SharePoint 2007, data access, and application architecture. Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to be highly charged, fast moving, and highly interactive. Be sure to check out his blog.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date