Some validation weirdness with Office Core

This one had me stumped for a bit.  I'm putting together some walkthroughs with Office Core on Sitecore 6.4.1 build 5, and whenever I tried to publish, I would get stopped in my tracks by the following validation error:

Clones, Versions, and Shared Fields

In Sitecore's release notes for 6.4.1 build 3 (110720), there's an interesting, if somewhat cryptic, announcement:

Clones are now treated as a whole instead of version-by-version, meaning that all versions on the cloned item must refer to the same source item. It is no longer supported that different versions on the cloned item point to different source items or that some versions on a clone do not refer to any source item. This restriction removes potential confusion about which items clones are referencing, and ensures that the value of shared fields is well-defined. If any existing clones in a solution reference different source items, the behavior of shared fields is undefined for these clones.

So, what does this mean? It's clear why shared fields could be a thorny issue for clones.  Unlike a proxy, which is a  copy of the original item in all regards except ID and path, the clone is an independent item with special  rules for the interpretation of null fields.

The Problem
The connection between a clone and its source is defined through the "__Source" field.  Basically, when the source field points to another item, Sitecore uses this item, rather than Standard Values, to pull default values for fields. The problem is that "__Source" is a versioned field, so there is nothing to prevent different versions of a clone from pointing to different objects, or having one version be uncloned.

Dipping a Toe into Open Source Development

I spent some time this weekend shaping my Gutter Icon code into a proper Github repo:

1. I took the class file and put it into a separate project.
2. I replaced the old namespace "SitecorePlayground" with the more official  sounding "SharedSource".
3. I serialized the Core content item that wires this up.
4. I created a package with the DLL and and the content item, and tested them in a blank solution.
5. I browsed among the various open source licences here and selected this one.
6. I put the whole thing on Github and added a Wiki.

Next step, getting it on trac.sitecore.net!  A fair bit of work for 20 lines of code, but quite satisfying.  Please comment if you end up using this in your Sitecore installation.  

My Sitecore Personal Trainer: Stack Overflow

There's nothing like getting your ego invested in your Stack Overflow rating (mine is a puny 173 at present), to get you working on your technical chops. I spent a few (too many) hours working on this question:

Defining Multiple Sites in Sitecore's Host File

Just discovered an odd little fact about how the sites/site node works in Web.config when defining multiple sites. There is an implicit wildcard functionality, so that if you have two host names, such as "Sitecore65" and "Sitecore65b", a site with hostname="sitecore65" will match both.   So if you want "Sitecore65B" to go to a different home item form Sitecore65, you have to put this entry first in Web.config:

       <site name="website2" hostname="sitecore65b" virtualFolder="/" physicalFolder="/" ...
       <site name="website" hostname="sitecore65" virtualFolder="/" physicalFolder="/" ...

Sitecore's multisite documentation mentions wildcard functionality, but from the way it is stated, I assumed this was explicitly specified with an asterisk:

Sitecore compares the hostName attribute (which may include wildcards) with the incoming URL

Oh well, you known what they say about assuming things...

Creating a Gutter Icon for Proxies

One of the true joys of Sitecore is the ease of customization.  We use proxies fairly extensively on our site, and a colleague recently complained that the Content Editor did not give a clear indication of whether an item is a proxy, and what is its source.  This inspired me to see if I could add a gutter icon to identify proxies, similar to the gutter clones icon that ships with Sitecore 6.4.   (The "gutter" is the area to the left of the content tree with icons, such as "My Locked Items", that can be toggled on and off.)  Like the clones icon, I wanted one that would navigate to the source item when clicked.  This is a fairly straightforward task, but I did have to lean on ReSharper's decompiler to see how the Sitecore guys built the clones icon.

Structs in C#

Just read a very good discussion on structs in Professional C# 4.0 and .NET 4 (Wrox Programmer to Programmer).

Here are the main points:

• structs are value types, so they get created and destroyed very fast.
• They are well suited for grouping together a small number of value fields, such as a pair of ints for X,Y coordinates.
• Because they are values, they do not need to be initialized with the new keyword.   
• You cannot override the default constructor, nor initialize fields inside a struct, except in a non-default constructor.
• If you create an instance of the new struct with new, the fields are initialized to their default values.  If you create the struct without new, you must manually initialized the fields before using them.

Poking around with this some more, I've noticed that creating a non-default constructor does not hide the default constructor, unlike classes.

Dreamcore Day 1 Musings

A very full first day at Dreamcore.  The day began with a keynote overview by CEO Michael Seifert on how OMS, content personalization, and CRM integration form a complete circle of customer engagement.   I was struck at how OMS is being woven into the Sitecore product.  For example, the page editor now provides a  interface for tagging content by marketing persona using a nifty feature called Persona Cards, and there is now a very intuitive automation designer that handles building personalization workflows.  Alexey Rusakov showed off more of what the page editor can do in 6.5, such as generating item clones and spinning off personalization rules.  Empower the content author!

Agile Estimation and Planning

I just finished Mike Cohn's Agile Estimating and Planning, a thorough and very readable treatment of how Agile works as a project planning methodology. Here are my takeaways:

Sitecore Hands-Off Deployment

Managing the Sitecore Web.config file across development, test and production environments can be a major headache for source control and deployment. Do you store the version you need for development in source control? And since this version differs from what's needed to run the production website, it's difficult to use the publish option to deploy changes to the website.

Fortunately, Visual Studio 2010 has added some very nice functionality for managing different flavors of Web.Config, through the Web.Config transform feature of the Web Deployment project. This feature allows you to specify, and check into source control, the specific changes you need to make to change a development Web.Config into a test or production version.

Steve Green has a useful post outlining this feature.