Sitecore Multi-Site Black Arts

I just came back from a very stimulating presentation at the New England Sitecore User Group by Rick Cabral of ISite Design on setting up multi-site environments in Sitecore.  Among the things I learned:

1. You can do some really nice stuff with pipelines.  For example, Rick's solution automatically changed web controls based on the site.   Let's say a  multi-site installation has a standard control for rendering a  breadcrumb, in use for sites A, B, and C, but site D needs a different breadcrumb rendering.  In Rick's solution, there's a main rendering folder, and a folder under each site.   The pipeline checks if there is a site-level rendering with the same name as the rendering attached to the current page, and swaps it in.
   
    This means that you can set up templates at an installation level, and attach presentation to them in standard values, but the behavior of this rendering can change based on the site-level overrides.  One point Rick stressed is that good architecture makes the developer's job easy--you just need to drop the customized control in the right folder and it gets picked up automatically.  The way the code and static structure reinforce each other is very elegant.  
2. Rick's solution had similar logic to allow templates to be overridden at a site level, with the pipeline checking the template at a site level and then at an installation level for the standard values.
3. The entire structure is reinforced by a very nice wizard that cranks out a new site with a mouse click.  Rick gave a strong plug to The Pragmatic Programmer for recommending this approach, and as an overall guide to good programming practices.
4. Wrap your templates in classes that implement template-specific interfaces.  Not only does this simplify development, but it also allows your site structure to drive functionality.  Rick gave an example of a LandingPage template, represented by an ILandingPage entity.  A breadcrumb control could know to stop when it hit an object that implemented this interface, or when it hit an object that did not implement IPage, preventing folders from appearing in the breadcrumb.
   
   Interfaces are important because they support multiple inheritance.  Rick gave an example of a Page template that inherited from a Metadata template, which contained a title field.  A control could be written to render an object that implements IMetadata, which exposes all the fields contained in the Metadata template.  This allows the Page template to be passed to any number of controls, each designed around different interfaces.
5. Have your base level classes handle null values intelligently, and save yourself a lot of headaches and 505 errors down the road.
6. Code-generation tools can be very useful for generating these objects.  ISite Design has a very nice tool set, and Velir mentions their Custom Item Generator on their website.   Rick mentioned that this  may come baked into Sitecore with version 7.0 ("Massive"). 
7. Have your classes expose lots of control values, and set these to intelligent defaults in the default constructor.  This reinforces good development practices.  For example, Rick's base web control class defaults to caching output, but this can be toggled explicitly if needed.
8. Twin Peaks (Sitecore 6.3) can be very helpful if you need to dynamically update content, for example, based on reviews or in a social networking context.  You can set up a separate servers for content authors and social networking input, and Sitecore will keep everything in sync, even allowing content authors to approve or reject content coming from the social networking server.
   Rick explained that it is not a good idea to update Web directly, as this will be overwritten with a full site publish.

Whew.  That covers most of it!  Thanks Rick for a very engaging evening.

Update: Rick Cabral's summary is here.