Silverlight Feeds - All your Silverlight feeds in one place.

Sponsors

Saturday, January 22, 2011

Maximizing your Silverlight LOB investment with Web Parts

by bartczernicki@gmail.com via Silverlight Hack on 1/22/2011 10:05:00 AM

Astract:  This article will show you how you can take advantage of the Silverlight architecture for easy deployment to web parts and easy client communication (intra web parts).  This article will amplify why Silverlight is still the technology of choice if you want to create modular functionality deployed as web parts into custom or SharePoint portals.

A few months ago Microsoft made the announcement that they are "repurposing" Silverlight from a general web technology in favor of HTML5.  They have backtracked a bit from this statement and have made statements like Silverlight has some "sweet spots" in line of business (LOB) applications.  Microsoft does a very poor job of defining these sweet spots and what they are.

Silverlight being a web browser plug-in offers some really nice deployment and integration capabilities; one of them being SharePoint and web parts.  This allows you to deploy Silverlight applications to existing custom portals, SharePoint 2003-2010 servers or other web part architectured sites with little/no additional code.  In my opinion this makes the Silverlight architecture very attrictive for intranet line of business applications.

Note: Additional details on this topic is provided in my new book "Silverlight 4 Business Intelligence", where I dedicate an entire chapter to Silverlight web parts. In the book you will see step by step instructions and code samples for the scenarios outlined below.

 

Silverlight as a Portable Web Part Module

Silverlight applications (XAP files) can be easily made into web part by simply surrounding the Silverlight application with a "web part wrapper".  This technique can be implemented via a ASP.NET Web Part interface, SharePoint 2003/2007 web part interface (deprecated) or the new SharePoint 2010 Silverlight Web Part.

Hosting Silverlight in web parts is as simple as "rendering" the XAP package inside the web part. 

Lets take a look an example of how to host an existing Silverlight application in a SharePoint 2010 portal using the new Silverlight web part.  SharePoint 2010 includes a new "Silverlight Web Part" which does exactly this.

SharePoint 2010 includes the "Silverlight Web Part" in the "Media and Content" section.

As long as the SharePoint 2010 server can access the URL location of the XAP file, you host the Silverlight application as a web part.  This means that SharePoint can host Silverlight content as a web part from a:

  • Remote Silverlight XAP file located on the internet
  • Document/SharePoint list URL location of the XAP file inside SharePoint
  • Another internet/intranet portal that is hosting the Silverlight application
SharePoint 2010 Silverlight Web Part requires just the Silverlight XAP file URL to render Silverlight content.
 
The SharePoint 2010 Silverlight Web Part also includes an additional parameter for initialization parameters passed into the Silverlight application before the content is rendered.  This is a nice feature; for example, if you want to let the Silverlight application know that it is being rendered in SharePoint to pull data from ShrePoint lists instead of portal services.
 
What if you want to create a Silverlight web part for SharePoint 2003/2007 or for an ASP.NET portal?  What if you want advanced features like web part communication configuration connections?  In those situations you will need to create a custom Silverlight web part wrapper or use an existing open source one.
 
Silverlight web parts are a VERY powerful feature that is often overlooked.  Imagine you have an existing ASP.NET MVC or ASP.NET web forms site that you want to host inside SharePoint.  This is not very easy without having already invested in a web part architecture.  However, with Silverlight hosting this content in SharePoint is trivial
 
Example of a full Silverlight dashboard hosted in SharePoint 2010 with NO CODE CHANGES (imagine doing this with another web technology if you didn't invest in web parts from the start; Silverlight's plug-in architecture pays dividends here)
 
 
 
Silverlight Web Part Communication 
 
Creating a single web part whether its an ASP.NET web part or Silverlight web part is fairly easy.  There is a lot of material out there to guide a developer through this.  However, web part communication gets very tricky in ASP.NET/SharePoint.  In these situations you will want an action on one web part to trigger a data refresh in the other web parts on that page.  This is where Silverlight really shines.
 
An example of three web parts, where an event on a single web part will update the content of the other two web parts on a page. 
 
In order to do this type of web part communication involves creating custom web parts with the provider and consumer interfaces explicitly defined.  Not only that, but traditional ASP.NET web parts post back and do not provide that "Ajax/web 2.0" feel.  Furthermore, when you have multiple layers of web parts (i.e. providers and consumers switching roles) then this gets very complicated with state management and the web part lifecycle.  Furthermore, interactivity (i.e. a slider moving and changing another web part contents in real-time) is not trivial as well.
 
Note: If you are not familiar with web part connections, look over the MSDN article that describes this.  As you can see the components involved: Web Part Manager, provider/consumer connections, web part interfaces, web part lifecycle all have to "play nice" with each other for this to work.
 
What advantages do Silverlight web parts provide:
  • Allows client-side, real-time communication between web parts without post backs
  • Allows communication between Silverlight and non-Silverlight web parts (using the Silverlight HTML bridge)
  • Simplifies the design/coding of the web parts by NOT having to implement web part interfaces, worrying about lifecycle management, which part is a provider consumer (you can of course do this if you want)
Silverlight web parts allow you to create very modular pieces of functionality inside Silverlight.  However, it also allows the SharePoint admin to expose the pieces of functionality that is interesting from the complete Silverlight application very easily in SharePoint with NO/LITTLE code changes.  Imagine if you have a great Silverlight application with MEF that composes the application in real-time.  You can leverage that composable and dynamic architecture into creating a modular SharePoint gallery that allows Silverlight web parts to communicate with each other based on what the portal admin or power user decide to place on the portal canvas.
 
How does Silverlight Web Part Communication Work? 
 
Silverlight web part communication has nothing to do with the web part framework provided in ASP.NET nor SharePoint!  It is actually natively provided with the Silverlight framework using the local communication APIs.   This means that if you have two Silverlight applications that utilize Silverlight messaging can be deployed a seperate web parts.  Furthermore, they can communicate between each other WITHOUT having to write additional web part framework code around providers/consumers/web part managers etc.
 
The primary mechanism for this is the LocalMessageSender and the LocalMessageReceiver classes.  For example, from the API documentation this all the code that is required to set up communication between two Silverlight applications:
 
// In the receiving application:
LocalMessageReceiver messageReceiver = new LocalMessageReceiver("receiver");
messageReceiver.MessageReceived += new EventHandler<MessageReceivedEventArgs>(receiver_MessageReceived);
try{messageReceiver.Listen();}
catch (ListenFailedException)
{MessageBox.Show("Cannot receive messages." + Environment.NewLine +"There is already a receiver with the name 'receiver'.","LocalMessageReceiver", MessageBoxButton.OK);}
// In the sending application:
LocalMessageSender messageSender = new LocalMessageSender("receiver");messageSender.SendCompleted += new  
EventHandler<SendCompletedEventArgs>(sender_SendCompleted);
 
 
In my book, I provide an example of two Silverlight web parts that can communicate between each other in SharePoint.
 
 
 
Note:  If you want Silverlight web parts to communicate with non-Silverlight web parts, this can be done easily using the HTML bridge.  For example, if a user clicked a Silverlight button this could trigger a post back and via the web part framework send the proper message via the agreed provider/consumer interface.  The part that is tricky is maintaining state between web parts and losing some of the client-side/non-flicker web part messaging.
 
 
Summary and Takeaways
 
This article hopefully showed you some of the advantages that Silverlight posseses when using web parts. Some of the key takeaways should be:
  • It is really easy to deploy a Silverlight application as a web part by simply "hosting it" in an ASP.NET web part.  This allows Silverlight applications to be deployed into custom ASP.NET portals or SharePoint 2003-2010 portals with no or minimal code changes.
  • SharePoint 2010 includes a new Silverlight Web Part that allows you to host local, remote or any Silverlight applications that are URL addressable.  Therefore, deploying a Silverlight application to SharePoint 2010 usually requires no additional code.
  • Web Part communication (which is not trivial to implement in advances scenarios) simply works without code changes inside Silverlight web parts using the local communication APIS.
  • Web Part communication within two Silverlight web parts happens on the client-side.  This provides real-time communication between two web parts without server postbacks nor page refreshes.  Silverlight web parts allow for many interactive scenarios that make UIs feel non-obsolete.
  • Advanced MEF scenarios can enable distributing Silverlight as seperate functional modules that can be deployed into portals dynamically.  This allows you to "break up" a larger Silverlight application into seperate Silverlight web parts that expose particular pieces of functionality.
If you want more details, excercises or code samples on this subject I dedicate an entire chapter to this topic in my book "Silverlight 4 Business Intelligence".
 
email it!bookmark it!digg it!

Original Post: Maximizing your Silverlight LOB investment with Web Parts

Subscribe

New Feed

Product Spotlight

Recently Updated Sources

Legal Note

The content of the postings is owned by the respective author. Silverlight Feeds is not responsible for the contents of the postings. This site is automatically generated and cannot be reviewed for abusive content. If you find abusive content on Silverlight Feeds, please contact us. Designated trademarks and brands are the property of their respective owners. All rights reserved.

Advertise with us