Print | posted on Tuesday, April 24, 2007 3:28 PM
Not unsurprisingly it is very straightforward to build an Office SharePoint Server Field Control for Silverlight (previously known as “WPF/E”) content, or so you would think…
We can simply take the same approach as detailed in the SDK article,
How to: Create a Custom Field Control, which renders a Windows Media Player control during presentation, and makes use of the
Asset Picker when in Edit mode.
For a Silverlight Field Control, we just need to alter the MediaPlayerHtmlMarkupFormat constant, to include the block of JavaScript needed to load Silverlight content, rather than the Object HTML element needed by Media Player:
However, for anything other than the dumbest Silverlight content, we have more to worry about. It’s reasonably straightforward to add additional details to the sample control to deal with things like the size of the control, background colour and so forth. The only decisions for these types of things are first, where to store that information, and second, if we can be bothered creating a custom Field Type.
However the problem with delivering a generic Silverlight Field Control is what to do about the additional assets required. The primary XAML file itself is no problem, that bad boy can just go into a Document Library, but the associated images, java scripts and so on also need to be handled.
In a simple implementation a Document Library could be suitable assuming you want publishing controls (otherwise just add them using a regular IIS Vdir). However for more flexible solutions, you need to consider how to avoid conflicts with common script files (e.g. main.js) and how relative paths within your assets will be resolved. Ideally these things would be defined upfront so that the designers creating the Silverlight assets don’t do anything too left field.
What other options would you like to see in a Silverlight Field Control?