In the spirit of helping new SharePointers along (see this post from Bil and this one from yours truly), here's a Top Ten list to start the New Year off on the right foot. For anyone about to dive into heavy SharePoint customization, this is a good list to keep handy (or to use for lining your cat's litter box, whichever you find more appropriate).
1. Simple HTML
Keep your HTML layout code as simple as possible. Use the minimum number of formatting elements (DIV’s, SPANs, Tables, etc.). SharePoint creates a tremendous amount of extraneous code at runtime; the less you add, the less chance for something unexpected to happen. Also, you’ll be cutting and pasting a LOT of code; fewer lines means fewer mistakes.
2. User Controls
Reuse as much code as possible by placing repetitious elements into user controls. Rather than repeating the layout code that defines web part zones and code areas on page after page, place it in an ASCX file, register the file location at the top of the page, and reference it in the page body. This creates a template-like effect for site definition pages in which you only have to modify one file to have a global effect. An added benefit is that code which cannot be executed within presentation files can be executed within a user control.
3. Custom User Menus
SharePoint menus take up a great deal of valuable screen real estate. There’s nothing magical about the left-hand navigation area; extract the menu elements and place them into collapsing DIV’s or pop-outs. While they’ll never be perfect, a basic set of menu layouts can free up 125 – 300 pixels of screen width. Place them in user controls to simplify maintenance.
4. Nested Style Sheets
SharePoint style sheets are a confusing maze of endless CSS code. Nest common code elements in your custom style sheets just like you would with HTML; create parent styles, indent each child style, and keep everything together in logical groupings. Copy existing styles from OWS.CSS and SPS.CSS into your custom sheet to overwrite the defaults and maintain compatibility.
5. Minimal Site Definitions
There are few occasions where more than one or two custom site definitions are necessary (in addition to the required SPS, SPSMSITE, SPSPERS, SPSSITES and STS, all of which can be replaced with a custom definition by modifying the WEBTEMP files). Each definition exponentially increases the amount of customization and future maintenance. Use the bare minimum number of definitions to meet the requirements.
6. Server Controls
Custom code elements that do not require user manipulation should be implemented as server controls instead of web parts. The layout is easier to design with fewer web part zones, the code is much more compact, and render times are much faster. Store them in the /Bin directory along with the user controls for layout.
7. Preserve Zone Names
Some functions, such as ‘Edit in DataSheet’ require a specific zone to be present on the page. To avoid erratic behavior, preserve the default zone names whenever possible but change their location to meet your requirements. This also reduces the amount of edits to the various SCHEMA.XML files.
8. Comments Before Deletions
Before deleting existing code, comment it out and test it with your modifications. Once you have a working page, go back and delete the extraneous elements one by one. There are some pages that absolutely must have certain elements in place – even if they’re hidden - or they won’t render properly. You’ll save yourself a great deal of frustration by working backwards through commented code than trying to add it back in later.
9. Assumption = Frustration
Never assume that the modifications you make in one definition will work in another. This is especially true of SPS and its deviations; the root portal definition is quite different from the subarea definitions. Diff the original files extensively before copying changes to a new definition. This rule applies in spades to administration pages, where there are multiple shared code structures and many one-off files.
10. Make CAML Your Friend
Much of what drives SharePoint lives in ONET.XML and SCHEMA.XML. The more extensive the modifications, the more you’ll need to work with these files. Learn the ins and outs of CAML and how to tweak it to meet your needs. Although at first intimidating, it’s nothing more than a structured XML superset. Begin by adding list definitions and move from there into creating custom lists and mastering views.
Happy SharePointing!!!
