Yesterday I posted about using the new RadControls for ASP.NET AJAX in MOSS, and I started moving the old controls in my current project over to the new ones.  Just now, I found a problem when I was converting the RadEditor from the old to the new.

In the Telerik online documentation for getting started with the RadEditor, they say that in a standard ASP.NET AJAX application, you need to utilize the App_GlobalResources and App_Data ASP.NET folders in order to use the RadEditor.

That's not any different for MOSS.

In the root of your SharePoint Web Application (\Inetpub\wwwroot\wss\VirtualDirectories\YourWebApp) create a folder named App_Data.  Drop in the RadSpell folder from the App_Data folder of the RadControls install directory (C:\Program Files\Telerik\RadControls for ASPNET AJAX Q1 2008).  Then, drop the RESX files from the App_GlobalResources directory located at the Telerik install root into the already present App_GlobalResources directory in your SharePoint Web Application root.

I think there's probably a better a way to do this using a Solution, but I'll worry about that later.  Not sure if we can deploy into those folders via a WSP - I don't think so.  I know there's a public property on the RadEditor that allows you to point to where the RadSpell directory is, but can't find anything for the RESX files.

Also, make sure you add the following line to the HttpHandlers section of your web config file, or else, spellcheck won't work:
<addverb="*"validate="false"path="Telerik.Web.UI.SpellCheckHandler.axd"type="Telerik.Web.UI.SpellCheckHandler, Telerik.Web.UI"/>

Anyway, here's a screen shot of the unskinned and unmodified RadEditor running in my local MOSS environment.  This is not tied into a publishing placeholder, but that's not what I'm using it for right now...

I've been a huge proponent of Telerik because of their very impressive controls, support, and documentation - let alone for the fact they are very easy to use.  Now that I've been working with SharePoint 2007 for a few years, I've found that Telerik's controls fit very nicely into MOSS.  Andrew Connell even created an integration whitepaper and some nice utility EXEs to help package the individual controls into WSPs to deploy them into MOSS.

Then, on April 15 of this year, Telerik released version 2008.1 of their new RadControls Suite for ASP.NET AJAX, formerly named 'Prometheus'.  I purchased my upgrade from the old RadControl suite to the Prometheus controls yesterday, and there was something that I noticed immediately which frightened me a little.  There's only one assembly - Telerik.Web.UI.ddl - and nowhere that I could see on the Telerik site that allowed me to get an individual control.

Uh oh. 

How do I get these amazing controls into SharePoint and start benefiting from that ASP.NET AJAX goodness?  Do I package the whole thing into a WSP? I hope not! That'll be a huge WSP file with all those skins getting packaged up!

I was worried, and started thinking that I was going to be stuck with a legacy version of some great controls, being forced to sit  here watching new versions go sailing past every three months.  No way!!!

I figured that there had to be a way, and if it took a massive WSP, so be it, so I started poking around the new control suite to see how it ticked.  There's no RadControls directory, so AC's walk-through documentation won't work.

I tested the RadSlider locally, and I asked myself, where do the images come from in the control?

I got out my trusty IE Dev Toolbar and took a peak.  I liked what I saw.

WebResource.axd!

Now, I don't care if this image is an embedded resource file or not.  It's not a direct reference to an image, and that's what matters.  What happens if a skin is applied? Where's the image then?

Office2007 skin:

IE Dev Toolbar:

Still a WebResource.axd. Excellent!

So - here's the deal.  Install the entire RadControls EXE which you get via your Telerik account on your SharePoint server.  Deploy the Telerik.Web.UI.dll to your SharePoint application's bin, and add the following line to the SafeControls block in the web.config

That's it...

Then, you can use any control in the entire suite just by adding the following Register tag to the page where you're using it

No more individual control references anywhere! Sweet!

For example - the RadTreeView control:

You can even deploy this inside your custom WSP by using the various Visual Studio project templates available on CodePlex.  I know of three that support deploying other assemblies, so finding them shouldn't be hard.  I'm partial to this one, and I know stsdev is really nice, as well.  You can even reference the Telerik control assembly server-side, too.  Just make sure you set the CopyLocal property of the reference to False.

You won't get IntelliSense for the controls, but as far as MOSS dev goes - what else is new, right?  There's plenty of documentation on Telerik's site to help with the control properties and client-side API.

Here's the new RadSlider with the Office2007 skin running in one of my MOSS environment:

I've started moving over all of the controls in my current project from the old version of the suite to the new version, and there's been some minor changes, but nothing of a pain at all.  The changes I have seen have been good ones, so it's been worth it so far.  Besides, these controls ROCK!  I haven't gone through and seen which ones work and which don't, but I'm sure it'll be similar to the old version of the suite.  I know the RadSplitter was a hassle before, will have to try it again with the new ones.  I've even noticed some performance gains over the old controls.

So, if you haven't picked up on it, I highly recommend these controls.  Not only will they completely expand your MOSS UI potential, but they will get you to install Service Pack 1 and configure ASP.NET AJAX in SharePoint if you haven't yet.  Remember, SP1 is required if you want to use ASP.NET AJAX, therefore, it's required to use these controls.

Having spent a great deal of time developing Microsoft Content Management Server 2002 solutions, I've found there's a bunch of stuff I miss from the MCMS API.  The single thing I miss the most:

CmsContext.Searches.GetByGuid(string) as HierarchyItem;

Being able to get any object - Channel, Template, Posting, Resource - by just it's guid was huge.  Even cooler was that you could grab an object out of anywhere in the hierarchy/taxonomy.  In SharePoint, you have to know the Web, List, and Item guid to find anything.  This one method in MCMS allowed a huge number of possibilities for custom dev with very limited coding time.

Another thing I miss from MCMS is the functionality of Connected Postings/Templates and an API that could CRUD them without hardly any effort.  I know Variations in SharePoint comes close, but IMO, it just doesn't seem to be at the same level and simplicity of MCMS.  Also, there's very little documentation around any of the Variation related objects because they've all been marked as internal.

Luckily, Michiel Lankamp figured this out - a long time ago - using Reflector (duh) and exposed that yes, everything in SharePoint is a list(thanks Matt). As Michiel points out, there's two variation lists. One called VariationSettings and one called VariationLabels who's guids are stored as Properties on the root web of the site collection.

Once you get the lists, how do you create the hierarchy? Check out Michiel's post to see how. Pretty clever...

I haven't tried this, and based on the four comments, not many other people have, either.  Also looks like it could be buggy.

Enable variations programmatically - Michiel Lankamp