WSS v2

Snow Web Part, Part Two - Crystallized

Todd Bleeker — Wed, 20 Dec 2006 13:33:00 GMT

The Snow Web Part I created last year still works on any SharePoint site (v2 or v3):

You can download last year's snow.dwp Web Part here. Just import it onto a page.

I thought it would be fun to release another simple, holiday CEWP.

(50 plus images in the AJAX-style slide show)

The Mindsharp staff enjoyed the images I showed them at SnowCrystals.com; so I asked the image owners if I could wrap their awesome photos into a Web Part. They gave me permission to proceed. I also thought I could use the opportunity to show off how the CEWP can use the RPC URL Protocol to access a List/Library in either WSS v2, SPS, WSS v3, or MOSS. So, let it snow, let it snow, let it snow.

Use the following steps (generic steps given to prevent WSS version confusion) to create a standard Picture Library, add the images, and point the CEWP at the Library.

Upload my snowcrystals.stp (WSS v2 version or WSS v3 version - both custom List Templates target the STS 1033 site definition; that is Team Sites, Blank Sites, and Document Workspaces using the US English language) into your list template gallery on the top-level site of any site collection.
Create a new Picture Library using the uploaded list template.

OR, if you are using a site based a site definition other than STS or in a locale other than 1033, or you just want to create the Picture Library from scratch, use these alternate instructions:

Download the snow crystal images (I made them all 200x200).
Unzip the images to your local file system.
Create a Picture Library named SnowCrystals.
Upload the images into the new Picture Library.

After the Picture Library is created, the following steps are required:

Ensure everyone that will see the Web Part has at least read access to the new Picture Library.
Navigate to Picture Library Settings. In the URL, you will see the List as a parameter in the QueryString. It looks like the bolded section below (the v2 version will not have escape characters, either is OK):
http://[site]/_layouts/listedit.aspx?List=%7B2F6C6FAC%2D7E9A%2D42C2%2DBA99%2DCC986C67D7AE%7D
Copy this List ID.

On the page that you want to display the snow crystals:

Put my snowcrystals.dwp CEWP onto any WSS page.
Choose Modify Shared Web Part from the Web Part's smart menu.
Click the Source Editor... button in the tool pane and at the top of the JavaScript modify the following constants:
Paste the List ID you copied from the URL into the LIST_ID constant as follows:
var LIST_ID = "%7B2F6C6FAC%2D7E9A%2D42C2%2DBA99%2DCC986C67D7AE%7D";

Optionally, change the wait seconds to the number of seconds you want each image to show before displaying the next image in the library:
var WAIT_SECS = 1;

If the Picture Library IS on the same site as the Web Part (easiest) continue on to the next step. Otherwise, change the URL constant to the Web Application (same as v2 Virtual Server including both protocol and domain - do not end with a forward slash). Also, change the ROOT_URL to the fully qualified location to the site where the SnowCrystals Picture Library is located. If the library's URL is http://portal/sites/subsite/SnowCrystals/Form/AllItems.aspx, change these two lines as follows (they default to the values for the current site):
var WEB_URL = LOC_HREF.substring(0, LOC_HREF.indexOf(document.domain))+ document.domain;
var SITE_URL = LOC_HREF.substring(0,LOC_HREF.lastIndexOf('/'));

to these:
var WEB_URL = "http://portal";
var SITE_URL = http://portal/sites/subsite;
Click Save and then Exit Edit Mode.
Be amused.

Much bigger and crisper images can be seen in the three galleries at http://snowcrystals.com. There are also lots of interesting articles about snow crystals including a scientific discussion about whether two snow flakes could ever be alike or not.

In my next post, I'll explain how the code inside the Web Part works and how it can be used in other scenarios.

From 40 to 50 to 60 to 12 in six years flat

Todd Bleeker — Mon, 18 Dec 2006 14:01:00 GMT

As was the “60 Hive”, the “12 Hive” is the starting place for everything SharePoint in WSS v3. I’ve mapped some of the key IIS virtual directories and built-in site definitions below:

But what is it about Microsoft versioning that goofs up all their version numbers? You may have noticed that I've changed the name of my blog from "the 60 Hive" to "the 12 Hive" to match the new WSS v3 structure. But, 60 --> 12, what is Microsoft thinking? Is this twice (6.0x2=12) the release or perhaps one fifth the release (60*0.2=12)?

Not that Microsoft has a good track record on this front. Consider the Microsoft Windows operating system was first labeled with standard numerical version numbers (Windows 1.0 through Windows 3.11), then by years (Windows 95, Windows 98, Windows 2000), and also by alphanumeric codes (Windows Me, Windows XP). All the while versions of Windows from 95 on have continued the standard numerical versions internally: Windows 95 is Windows 4.0, 98 is 4.10, 2000 is (NT) 5.0, Me is 4.9, XP is (NT) 5.1, 2003 is (NT) 5.2, and Vista is (NT) 6.0 (excerpts from WikiPedia.com).

Windows Operating System Versions
• Windows 1.0
• Windows 2.0
• Windows 3.0
• Windows 3.1
• Windows 3.11
• Windows 3.51 (NT)
• Windows 95
• Windows 98
• Windows 4 (NT)
• Windows 2000
• Windows ME
• Windows XP
• Windows 2003
• Windows Vista
(more details here)

While officially part of the operating system Windows SharePoint Services version 3 (WSS v3) is the foundation for Microsoft Office SharePoint Server 2007 (MOSS). Coupled with tight integration in the Office clients and WSS v3 feels like it is part of Office. But the Office team hasn’t done much better on this front:

Microsoft Office Versions (excerpts pieced together from various sources and just from my memory)
• Office 3.0 released August 30, 1992: CD-ROM version: Word 2.0c, Excel 4.0a, PowerPoint 3.0, Mail (repackaged as Office 92).
• Office 4.0 released January 17, 1994: Word 6.0, Excel 4.0, PowerPoint 3.0.
• Office for NT 4.2 released July 3, 1994: Word 6.0 [32-bit, i386 and Alpha], Excel 5.0 [32-bit, i386 and Alpha], PowerPoint 4.0 [16-bit], "Microsoft Office Manager".
• Office 4.3 released June 2, 1994: the last 16-bit version; Word 6.0, Excel 5.0, PowerPoint 4.0, Mail 3.2 and in the pro version, Access 2.0. Last version to support Windows 3.x.
• Office 95 (7.0) released August 30, 1995: Word 7 for Windows 95, etc. - coincided with the Windows 95 release.
• Office 97 (8.0) released December 30, 1996: Word 97, etc. was published on CD-ROM as well as on a set of 45 3½-inch floppy disks), was Y2K safe with Service Release 2.
• Office 2000 (9.0) released January 27, 1999: Word 2000, etc. Last version to support Windows 95.
• Office XP (10.0) released May 31, 2001: Word 2002, etc. Last version to support Windows 98/ME. Improved support for working in restricted accounts under Windows 2000/XP
• Office 2003 (11.0) released November 17, 2003: Word 2003, etc.
• Office 2007 (12.0) released November 6, 2006: Word 2007, etc.
• Office ???? (13.0) will never be released, Microsoft is skipping Version 13 and going straight to Office 14.0

So, I predict that a few years from now my blog will be renamed to “the 14 Hive” (that sounds hard to say, doesn't it?).

As an aside, I’ve been traveling and training for the last 12 (like the 12 Hive) of 15 weeks (yikes!). My evenings have also been very full learning, writing courseware, learning, writing book chapters, and learning. Never stop learning or you become an old dog (I guess) - no new tricks, right?

Watch for new tricks in the coming weeks.

PS: 40 (four ohhh) was FrontPage Server Extentions 2002, 50 (five ohhh - like the TV show) was SharePoint Team Services, 60 (six ohhh) was Windows SharePoint Services 2.0, and 12 (twelve) is Windows SharePoint Services 3.0. It's not twelve ohhh but at first it's hard not to say that.

Kevin Buchan's OWA replacement CEWPs

Todd Bleeker — Sun, 20 Aug 2006 18:10:00 GMT

Kevin took the code from my recent post and created these CEWP DWPs. Each has a "New" button for its own element type. In his own words, "It's a crazy simple solution." Click on each image to download a zipped version of the DWP file.

My Outlook Calendar:

My Outlook Contacts:

My Outlook Inbox:

Enjoy,

CEWP vs. OWA Web Part

Todd Bleeker — Thu, 17 Aug 2006 08:59:00 GMT

More CEWP treasures languishing on my hard drive. I haven't checked to see if others have posted similar CEWP ideas but I doubt it.

The Out-of-the-Box (OOB) OWA Web Part initially looks like this:

It must be configured (something most user’s find difficult):

And it has limited functionality, you are often prompted to authenticate again, and it takes longer to load than the rest of the page:

The following CEWP lets users that have the Outlook client on their desktop work with any folder in a much richer interface than the OOB OWA Web Part. Since it just shows the local folders from Outlook, it also doesn't require configuration like the OOB OWA Web Part does. The Inbox and Tasks are used in the code sample but it could show Contacts, a public folder, etc. The sample also shows two folders but you can just show one or show a whole bunch organized within HTML however you’d like to display them. Of course, it’s only as up to date as Outlook:

<OBJECT classid="CLSID:0006F063-0000-0000-C000-000000000046"

width="100%">

</OBJECT>

<OBJECT classid="CLSID:0006F063-0000-0000-C000-000000000046"

width="100%">

</OBJECT>

Yep, that’s it -- amazing isn’t it. Not really, it’s just using an object already installed on the desktop along with Outlook. So, you get all the functionality that you would normally have in Outlook on the Web page.

Unfortunately, none of these options provide the ability to create a NEW email message. So, I created this CEWP that has all the code necessary to create a new message. I just call the JavaScript on the OnClick of a button. I’m sure that the interface and the code could get a lot fancier (new Task, new Contact, etc.) but you get the idea (script does not work with Outlook 12):

function genNewEmail()

{

try

{

o = new ActiveXObject("Outlook.Application");

if(o)

{

mailFolder = o.getNameSpace("MAPI").getDefaultFolder(6);

//You could also use custom forms like IPM.Note.CustomForm

mailItem = mailFolder.Items.add("IPM.Note");

mailItem.Display(0)

}

catch(e)

{

window.status = e.Message;

}

</script>

When you click on the button you should get the new message dialog from your local Outlook installation.

PS: Watch out, code pasted into a blog post like this can introduce line breaks and odd spacing that can cause problems. I try to keep my lines shorter than 80 characters but look for unnatural line breaks.

Menu Content Editor Web Parts

Todd Bleeker — Tue, 15 Aug 2006 15:50:00 GMT

Try this script in a Content Editor Web Part (CEWP) for dynamic generation of a mouseover menu with cascading options.

Before Mouseover:

After Mouseover:

<SPAN class="ms-HoverCellInActive"

style="CURSOR: hand"

onmouseover="MainMenu(this);"

onmouseout="this.className='ms-HoverCellInActive'"

nowrap valign="bottom"

</SPAN>

// Generate dynamic menu example

// todd@mindsharp.com MindsharpBlogs.com/Todd

// Last updated 03/24/2006

// Please don't delete this header

var IMG_PATH = "/_layouts/images/";

var SEP = ", ";

var menu = document.getElementById("menu_WPQ_");

function MainMenu(span)

{

try

{

this.className = "ms-HoverCellActiveDark";

var options = new Array(8);

options[0] = "http://www.altavista.com, AltaVista";

options[1] = "http://web.ask.com, Ask";

options[2] = "http://www.google.com, Google";

options[3] = "http://www.hotbot.com, HotBot";

options[4] = "http://search.lycos.com, Lycos";

options[5] = "http://search.msn.com, MSN";

options[6] = "http://www.search.com, CNet";

options[7] = "http://search.yahoo.com, Yahoo!";

//Define a WSS dynamic smart menu

if(menu)

{

//Add an option

CAMOpt(menu, "option1",

"document.location.href=\"http://wss1\";",

IMG_PATH + "aca16.gif", "Menu tooltip is broken");

//Add a Seperator

CAMSep(menu);

//Add a submenu with two options

var opts = CASubM(menu, "More Options",

IMG_PATH + "active.gif", "submenu tooltip also broken");

var opts11 = CASubM(opts, "Option 1.1",

IMG_PATH + "acl16.gif", "");

CAMOpt(opts, "Option 1.2",

"document.location.href=\"http://sps1\";",

IMG_PATH + "acl16.gif", "");

for(var i=0; i<options.length; i++)

{

option = options[i].split(SEP);

optionUrl = option[0];

optionName = option[1];

CAMOpt(opts11, optionName,

"document.location.href=\"" + optionUrl + "\";","", "");

}

OMenuInt(menu_WPQ_, span, 0, 0, 0);

}

catch(e)

{

alert(e.Message);

}

</script>

Here is flatter menu based entirely on CSS (rather than JavaScript) hung on a hyperlink so it must be clicked to see the menu:

Before Click:

After Click:

<style>

.ms-SrvMenuUI

{

display:none;

}

.ms-HoverCellInActive

{

border: none;

margin: 1px;

background-color: transparent;

}

.ms-HoverCellActive

{

border: #f4c660 1px solid;

background-color: #e1ecfc;

}

</style>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/google.gif"

onMenuClick="window.location.href='http://google.com';"

>Google</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/msn.gif"

onMenuClick="window.location.href='http://msn.com';"

>MSN</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/altavista.gif"

onMenuClick="window.location.href='http://Altavista.com';"

>Altavista</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/ask.gif"

onMenuClick="window.location.href='http://Ask.com';"

>Ask</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/hotbot.gif"

onMenuClick="window.location.href='http://HotBot.com';"

>HotBot</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/lycos.gif"

onMenuClick="window.location.href='http://Lycos.com';"

>Lycos</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/search_com.gif"

onMenuClick="window.location.href='http://Search.com';"

>Search.com</ie:menuitem>

<ie:menuitem

iconSrc="http://www.highdots.com/website-ranking-checker/images/search_engines/yahoo.gif"

onMenuClick="window.location.href='http://Yahoo.com';"

>Yahoo!</ie:menuitem>

</menu>

<div class="ms-HoverCellInActive"

onmouseover="this.className='ms-HoverCellActive'"

onmouseout="this.className='ms-HoverCellInActive'">

<a id="menuLink"

style="CURSOR: hand"

onclick="JavaScript: if(!myLinks.isOpen())

myLinks.show(this, true, 0, 0, 0);"

tabindex="0">

Search Engines

</a>

</div>

I wrote these a long time ago and I didn't vet them for this post but I couldn't see waiting any longer to share them with everyone.

Flash Content Editor Web Part

Todd Bleeker — Tue, 15 Aug 2006 15:15:00 GMT

I played with embedding Flash content into a CEWP a long time ago. Put the following object tag into a CEWP did what I needed it to do:

</object>

It looks something like this:

More flash clocks here: http://beeks.eu/Screensaver.htm

HTH,

PS: I've had this on my blog post list for ages... where does all the time go?

AJAXian Web Parts in WSS v2 (SharePoint 2003)

Todd Bleeker — Tue, 15 Aug 2006 14:56:00 GMT

The slides I used, a working code project, and instructions to install it were uploaded to Mindsharp's Premium Content page. I will be updating this example for WSS v3 (SharePoint 2007) later this year. My plan is not to use Atlas but to leverage the underlying AJAXian framework built into WSS v3. Stay tuned.

Enjoy,

My Tech Ed Code Demos and Speaker Notes

Todd Bleeker — Tue, 27 Jun 2006 12:26:00 GMT

As promised, my TechEd code demos and speaker notes from Tech Ed Boston were posted on Mindsharp's Premium Content page last week.

Todd Bleeker's Tech Ed SharePoint Feature Demos
Todd Bleeker's Tech Ed SharePoint Content Type Demos

Enjoy,

Subwebs On The Quick Launch (No Assembly Required)

Todd Bleeker — Fri, 17 Mar 2006 17:15:00 GMT

Subwebs On The Quick Launch

This Web Part has been burning a hole in my TODO list since I put out the beta bits to several dozen people on December 2, 2005 (in fact, I've was working on this solution since before TechEd 2005 and during PDC last year). I've gotten tons of positive feedback on this and my updated Search Web Part and thus far I have no bug reports. I just haven't had the wherewithal to put the finishing touches that I personally want to add before releasing the Web Part (several desirable, if minor, enhancements are listed below). But, I must face the fact that I will not have time to individually implement all these enhancements myself. So, rather than waiting another few months before releasing this, I thought I would just post what I have and see if the community can help me complete this task. You can download the zipped Subwebs On The Quick Launch DWP from the Mindsharp Premium Content page.

As I'm sure you know, navigation in SharePoint 2003 Team Sites (WSS Webs with a Quick Launch bar) is challenging. The biggest contributor to this challenge is the fact that the subwebs of a given Web are not intuitive to find. There are a half dozen ways to navigate to them but they all require at least two unintuitive clicks from the home page. Novice SharePoint users typically cannot find these subwebs, even moments after they create one. The navigation I like to use (least clicks and scrolling) is Site Settings > Manage sites and workspaces. From this page I can see a categorized list of all the immediate subwebs I have access to (one of the few things in WSS that is security trimmed).

So, I set about finding a way to put this list of subwebs on the home page where they can easily be discovered. I tried all sorts of approaches to this problem including AJAXian calls to SharePoint's own Web Services. But "no joy". Then, about a three quarters of a year ago I had an epiphany; since I always know the address of the page that does show the list I want to display, why not use a hidden iframe and just pull the pieces that I need out? It worked!

I wanted to add the subwebs to the Quick Launch bar in a way that would be intuitive and consistent with the links that are already there. Since everybody loves a choice, I gave the Subwebs On Quick Launch Web Part lots of options too. The default is a very basic, security trimmed, alphabetically sorted listing of the immediate subwebs. But you can choose to add sections, icons, tooltips, change the sort order; you can even add a menu I call "Down To" to the right of the "Up To" link on the top nav. These setting are managed by setting variables near the top of the embedded code. Also, I've tried to keep all the literals in variables so that Internationalization (I18N) and Localization (L10N) to another language should be relatively easy.

Here is the list of additional enhancements that I'd like to see made to this component followed by a few screen shots of the Web Part in action:

Since this data doesn't change often, I'd like to implement a JavaScript call to just retrieve the HEAD of the page in the iframe. If the content length (stored in a cookie) is the same as it was before I'd like to just use the HTML previous generated (also stored in a cookie). Estimate: 3-6 hours.
Add a SECTIONS_ONLY option: No subwebs would be shown, only section headers with links to the Manage Subwebs page.
Add a LIMIT_DISPLAY_NUMBER option: After this many subwebs have been iterated, a More... link to the Manage Subwebs page would show. This would help where there are tons of Subwebs to a given parent Web.
Add a SLIDE_QUICK_LAUNCH option: The top nav with the "Down To" menu would still show but the entire Quick Launch would be mostly hidden. It would just have the right edge showing and when the user placed their mouse over the edge, the entire Quick Launch would slide out long enough for the user to make a selection. However, if they moved their mouse off of the Quick Launch without making a selection, it would slide back to the left with just the right edge showing.
Add a QUICK_LAUNCH_TOP_NAV option: Using the same technique I've used to place the subwebs into the "Down To" menu in the top nav; this option would take all five sections of the default Quick Launch and move them into the top nav (probably just under the Home link). The entire Quick Launch would then be hidden but all the options would still be available. I started this one so it might look something like this.

Please let me know if you are interested in helping me add any of these enhancements.

Remember, you can get your free copy of this Web Part from the Mindsharp Premium Content page.

What follows are some screenshots of the Web Part in action.

The basic modified Quick Launch:

The modified quick launch with a few options enabled:

The modified top nav Up To link with a "Down To" menu option:

The modified top nav Down To menu with a few options enabled:

What other features would you like to see added to this Web Part?

Get the Subwebs On the Quick Launch DWP and deploy it to one of your Team Sites (or Document Workspaces, it is not intended to work with SPS Areas - they have their own navigational scheme) to see what it is like. If you like what you see but want to use it more widely across your SharePoint farm, be sure to check out my Guidelines to Centralize SharePoint Style/Script Customizations.

Happy St. Patrick's Day! Luck O' The Irish to you.

Guidelines to Centralize SharePoint Style/Script Customizations

Todd Bleeker — Fri, 10 Mar 2006 15:25:00 GMT

It's no secret that I think that the Content Editor Web Part (CEWP) rocks:

It is easy to export and reuse elsewhere.
It is easy to send to your friends for them to use.
It is not tied to the site definition ID or the LCID.
It always overrides any previous style/script definition (because of it's position on the page).
It is easy to remove when you no longer need it.
It can be hidden from view so that only it's effects are seen.
It is already on your server: No "Assembly" Required

In fact, most of my CEWP solutions start on a given page trying to solve a given problem. If you have followed some of my articles, you know that my solutions don't usually stop there.

This post is intended to get you past a one-off solution (which I will continue to showcase as they are the easiest to understand) to a wider deployment that doesn't result in replicative copies of the same code being propagated across your farm. In other words, a more maintainable solution; a solution that will easily move from v2 to v3.

Let's take the simple example of hiding the Quick Launch bar (always a great place to start). As I describe here: a CEWP with the code embedded in it can be placed into the Page Web Part Gallery, the Site Collection Web Part Gallery, and/or the Virtual Server Web Part Gallery so that end users can drag and drop it into situations where they will benefit from it most. Of course, each time it is placed onto a page, a copy of the code is placed onto the page embedded within the Web Part.

The trouble comes when you want to alter every instance of the original code within each of the Web Parts already in use. Or, you want the effects to be realized 1) on every instance of a Web Part Page, 2) on every Web Part Page in every Web, or 3) across your entire farm.

Problem: Maintaining deployed code

Continuing with the Quick Launch bar example, let's say that hiding the entire Quick Launch was the solution that the demanders were clamoring for. So, I created a CEWP that embedded that functionality and gave it to my users to put in whatever context they saw fit. After a few months there may be dozens, even hundreds of instances of that code on various Web Part Pages throughout my farm. The demanders are happy until one day Bob (God love him) discovers a bug in my solution (God forbid). Or perhaps on a creative day I (God love me) added a new feature to the existing code and want roll that out to everyone. I could send out an email that says something like:

Attention everyone, Bob discovered an anomaly in the Hide Quick Launch Web Part so if you used that Web Part on any of your pages, please remove it and add in the updated version from your Virtual Server Web Part Gallery.

OR

Attention everyone, you will love the new feature I added to the Hide Quick Launch Web Part so if you used that Web Part on any of your pages, please remove it and add the updated version from your Virtual Server Web Part Gallery. You'll love it.

Of course, everyone will immediately remember everywhere that they used that Web Part and rush out to replace it, right?

What to do?

Fortunately, you have several options that vary in scope but each solution requires pre-use Web Part dependencies. Pre-use means: certain steps that must be taken before the Web Part can be dragged into a Web Part Zone. I detest pre-use Web Part dependencies. I much prefer my Web Parts to contain everything that they require as embedded, URL accessible class resources. But, alas, that option isn't available with the CEWP. So, lets explore the potential options:

Solution 1: Link to the code rather than embedding it (scope remains the instance page but the source is centralized)

Start with a working CEWP embedded with code that does something that you want to do.
Copy the style/script code from the CEWP's Source Editor into a text file. The file extension that you use will not matter and the code does not require any change.
Upload the text file into a document library accessible to everyone that could potentially see the CEWP. If the file was called QuickLaunch.css and the document library was called CodeLibrary and it was located in the root of the wss1 virtual server. The fully qualified URL to the document would be:
http://wss1/CodeLibrary/QuickLaunch.css
In some circumstances, a root relative URL will suffice (I tend to use these whenever possible) but most of the time, to get portability, you will need the full URL.
Remove the style/script code from the existing CEWP or add a new CEWP to a test page and set the Content Link to the URL of the text document that contains the code. So, clicking on the Source Editor... button would present an empty dialog box and the Content Link would take us to a page that contained the code that used to be in the Source Editor. Click on the Test Link link. If SharePoint asks if you want to open or save the file you know you have a valid link, you can choose cancel and continue with these steps.
Click OK or Apply and you should see that the Web Part is still functioning as it was when the code was embedded.
Export the Web Part as a Dashboard Web Part (DWP).
Place the DWP into a Gallery if you like.

Now users can add this Web Part to any page they like. If you need to fix Bob's bug or deploy a new feature you simply upload the text file with the new code overwriting the existing text file. Note that if the text file, the document library, the Web, or the Virtual Server are not available to the consuming page, the CEWP will cease to work properly. The crux of a pre-use Web Part dependency is it's dependency on something other than itself and the Web Part Framework.

Solution 2: Embed the code in a direct-mode page in your custom site definition (scope becomes every instance of the direct-mode page)

If the solution you are looking to implement is only applicable to one page in a given site definition and will always need to be implemented on that page, you may want to go straight to the source and modify the direct-mode page (this is not supported by Microsoft but may be invaluable anyway). Of course, you will need write access to the ASPX pages in your custom site definition on each Web server to make this solution work.

Also, given you have access to this page, you may want to consider other ways of accomplishing your goal. With the CEWP you only have client-side tools like JavaScript and CSS. But within this environment, you can modify everything outside of the LinkBar and WebPartZone containers and all ghosted pages will adopt your changes. I'm sure that you don't have any unghosted pages, but if you did, they won't see these changes unless you reghosted them using the Ghost Hunter Web Part in Maurice's Web Part Toolkit (a must have tool). FWIW, I run a ghosted-only shop.

So, in the direct-mode page, I wouldn't hide the Quick Launch using JavaScript, I would just delete the table that generates it so that it isn't sent to the browser in the first place. However, there are many times when the style/script you want to run won't change at all.

The important thing is where you place the code on this page. Remember, cascading code cascades. So, if you put your style/script overrides in the wrong place within this file; it is your code that will be overridden, not SharePoint's.

I typically place my code just before the tag. That way I can be relatively certain that my style is overriding any built-in SharePoint defined styles but any CEWP can still override these styles again on any instance page.

SharePoint places most of its script wherever the <form>tag is placed. So, I typically place my <script>... code immediately following the <form>tag. Keep in mind that frequently client-side JavaScript will need the DOM in the browser to be completely loaded before it can run (think of it like EnsureChildControls in a Web Part). So, running your function on window.onload will likely change the sequence in which the JavaScript executes. Similar to a left outer join in SQL requiring left outer joins on subsequent tables, when you start using window.onload to run functions you will likely need to run all subsequent functions on window.onload so that the order is preserved.

Check out this cross-browser window.onload code I "kyped" from somewhere (?credit original source here?) and then modified to meet my needs:

Solution 3: Embed the code in an AlternateCSS or CustomJsUrl file (scope grows to every page in an entire site definition)

If the solution you are looking to implement is applicable to every page in a given site definition and will always need to be implemented, you may want add your code to the override files I explain my Custom Site Definition Recommendations article on Mindsharp's premium content site (similar details are also in my Advisor article). Of course, you will need write access to the these override files for your custom site definition in the 60 hive on each Web server to make this solution work. Unfortunately, the direct-mode pages in your custom site definition only refer to the default, farm-level ows.css file using a static HTML link. So, to support AlternateCSS, all the direct-mode pages in your entire custom site definition will need to be modified slightly. I advise changing this link to use SharePoint's CssLink server control. Fortunately, you can change this globally and simultaneously from VS.NET for all 100+ ASPX pages in your custom site definition using the following steps:

Open VS.NET and choose Edit > Find and Replace > Replace in Files (Ctrl+Shift+H) from the VS.NET menu
Enter this text in the Find what text box:
Enter this text in the Replace with text box:
Enter this text in the Look in text box:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\[sitedefinition]
where [sitedefinition] is the subdirectory where your custom site definition exists
Ensure that Look in subfolders is checked and that the File types is changed from *.* to *.ASPX
Click on the Replace All button.
Confirm the warning that this can't be undone and VS.NET should replace the link in all files in the custom site definition.

Using CustomJSUrl requires no direct-mode page changes.

Again, given you have access to these custom site definition files, you may again want to consider other ways of accomplishing your goal. But usually the client-side JavaScript and CSS that you developed using the CEWP will not require much, if any change. Just realize that this code will now be used on every page of every Web that is based on your custom site definition.

This is a relatively easy change to make once your site definition is ready. You simply copy all of the code inside of the identifying tags into the appropriate file. For instance, if the CEWP had the following style code:

You would copy only the following CSS code into the file identified by the AlternateCSS attribute in the Project element of your custom site definition's ONET.XML file:

.ms-nav{ display: none; }

Note that the style tags are not needed because this code is now included on the page within a file that is referenced by the href attribute of a stylesheet link in the underlying HTML:

Similarly, JavaScript will not need the surrounding script tags. For instance, my Disable Right Click CEWP has the following script code to prevent right clicking on the page:

You would copy only the following JavaScript code into the file identified by the CustomJSUrl attribute of the Project element of your custom site definition's ONET.XML file:

if(typeof browseris != 'undefined' && browseris.ie)
{
document.oncontextmenu = function(){return false;};
}
else
{
document.oncontextmenu = "return false";
}

Note that the script tags are not needed because this code is now included on the page within a file that is referenced by the src attribute of a script tag in the underlying HTML:

Solution 4: Embed the code in one of SharePoint's built-in files (scope grow to every page in the entire farm)

If the solution you are looking to implement is applicable to every page in EVERY site definition and will always need to be implemented, you may want add your code to the files that are built-in to SharePoint. I don't necessarily recommend this option but for some it will be the best option, especially if you started using SharePoint with the out-of-the-box site definitions. Of course, you will need write access to both of these files and, since they are owned by Microsoft, any changes that you make to them could be overwritten by an upgrade or service pack.

My approach to this has been to create my own files to keep my farm-level style/script code separate from Microsoft's and then I only have one reference in SharePoint's files to my custom code. So, I add a reference to my farm-wide custom CSS file from the built-in CSS file that is included on every Web Part page in the farm. I do this by adding the following code to the bottom of the built-in .\60\TEMPLATE\LAYOUTS\1033\STYLES\OWS.CSS file:

@import url("/_layouts/1033/Custom/ows.css");

This will make the styles defined in the referenced file applicable to every page in the entire farm. Like Solution 3, the contents of the custom ows.css file should not include any style tags but, of course, you will need to create a file (in this example called ows.css in the Custom folder, even if it is initially just an empty file). Also note that on Site Settings page for a SharePoint Portal Server there is a special way of referencing farm-wide CSS file to styles unique to the farm. The URL can be set in Site Settings > Change portal site properties and SharePoint site creation settings > Custom Cascading Style Sheet. The textbox is blank by default and I haven't tested where these styles would be inserted into the cascade (I don't do much with SPS).

Similarly, I add the following code to the bottom of the built-in .\60\TEMPLATE\LAYOUTS\1033\ows.js file (but above all the SIG lines):

//Add custom script to head of every page in the farm
try
{
var head = document.getElementsByTagName("head");
if(head)
{
    var script = document.createElement("script");
    script.language = "javascript";
    script.type = "text/javascript";
    script.src = "/_layouts/1033/Custom/ows.js";
    script.defer = true;
    head[0].appendChild(script);
}
}
catch(e){ /* ignore */}

This will append the script defined in the referenced file to the head of every page in the entire farm. This is obviously after the built-in farm JavaScript but before script inserted at the <form> tag is defined. Again, like Solution 3, the contents of the custom ows.js file should not include any script tags.

I trust these tips will help everyone implement a more maintainable solution that will smoothly migrate, if needed, to the next version of SharePoint.