Prior to my current role, I spent a lot of time with SharePoint as a development consultant in Microsoft Services. Along the way I picked up some tips, tricks, and hacks that I've found useful. I realized recently when helping a coworker that I haven't posted any of this on my web site, so here's my first installment of tidbits that I hope you'll find useful in your own development efforts.
Content Editor Web Part
The Client-side Swiss Army Knife
The Content Editor Web Part may not look like much at first glance, but it's actually quite powerful. When first loading the part into a page, it displays the following message:
To add content, open the tool pane and then click Rich Text Editor.
This is a bit misleading. It should actually read something like this:
If you are a wimp and need your hand held by a WYSIWYG HTML editor,
go ahead and click Rich Text Editor,
but Source Editor is where the real action is at.
With the Source Editor dialog, you can edit the raw HTML that the Content Editor will render. Here are a few examples of how this can be useful.
CSS Spot Treatment
When customizing the look and feel of a SharePoint site, you may find yourself needing to make tweaks to individual pages. One instance where I ran into this was while theming an internal site; I was asked to turn the Quick Launch links into drop caps (bumping up the first letter sizes) just for the home page and nowhere else on the site. This can be a royal pain to deal with on a page by page basis, especially if it involves modifying built-in UI elements that you can't tweak on the server.
The Content Editor Web Part comes to the rescue by enabling you to inject a <style> blob for a specific page. Since it's inline, these styles take precedence over the CSS files linked by SharePoint, so you can override the default look and feel to your heart's content. And by setting the Content Editor's border style to None, the Web Part itself will be hidden from view... all the user will see are the effects of your <style> tag.
This example Web Part uses this technique to turn a vanilla SharePoint site into jasonmauer.com fanboy land. The page logo (the little house) is hidden, the banner area is adjusted and given background imagery, the silly "Quick Launch" text on the side is removed, and the title text is scooted to fit. All of this is accomplished with a few CSS overrides of the default SharePoint styles. And since the Content Editor is built-in, deployment is a snap... just import the customized .dwp file.
a stock SharePoint team site with the jasonmauer.com Header Web Part applied
Poor Man's Widgets
A frequent request during my SharePoint hacking days was to add a search field to a page for some specific use. (Most of the time this was a shortcut to the parent portal's search engine, which I'll talk about more in another post.) For this example I've built three different parts for MSN Search, Google, and Yahoo! Search respectively. The only difference in implementation is the URL referenced; you can easily change this to point to something else.
One restriction that the Content Editor does place on your HTML fragment is it can't contain a FORM tag. (This could potentially cause conflict with the server form used for postback and viewstate.) A bit of Javascript is used to get around this by assigning the textbox value to window.location.href.
call our toll-free number now and get not one, not two,
but THREE search parts at no extra charge!!!
If you take a peek at the HTML behind this part, you'll see the text "_WPQ_" in a few places. This is a token for the current Web Part ID; SharePoint replaces all instances of "_WPQ_" with the actual ID of your Web Part for you automatically. This is handy for making sure the IDs of our fields don't step on anyone else's in the current page.
Script Ninja
Just like embedding CSS styles and HTML tags, you can also use the Content Editor to insert inline script into a Web Part Page. Add custom items to a list context menu... annoy users with alerts... whatever you can dream up. (You'll have to use your imagination because I didn't build an example for this one. :)
HTML Integration
Another frequent requirement is to display information from another web application in a SharePoint page. You could build a custom Web Part in Visual Studio, or you could use the Data View Web Part to display data from a Web service the application exposes. The first approach offers a lot of flexibilty at the expense of development effort, while the second approach has some limitations (such as only being able to make one request for data).
The Content Editor offers another option: HTML integration with the IFRAME tag. Sometimes the simplest solution is the best, and an IFRAME can pull in another web page with one line of code. You may need to build a Web Part sized page in the other application in order to fit within the bounds of a Web Part, but often this is less work than building and maintaining a separate Web Part interface.
What about the Page Viewer Web Part, you ask? Besides the fact that can be a performance laggard, the Page Viewer makes the page request from the server side, whereas the Content Editor IFRAME method is requesting the page from the user's browser. As a result, the IFRAME approach leverages the user's identity for the request instead of the server's.
The example below embeds the PDA version of Google into your page, which happens to be nice and small. Do a search and the results appear in the part without causing a page reload. This behaviour is handy for updating information; for example, a stock ticker mini-page could refresh every 15 minutes and not hose the user's SharePoint session.
Summary
The Content Editor Web Part is your ticket back to HTML land while in the realm of a Web Part Page. It's quick, flexible, and doesn't require compiling, a custom assembly, or registering as a safe control (since it already is). Add it, edit the HTML source, and export to a .dwp... voila, a custom Web Part ready to deploy.