The Mikkelsen Component Model

I recently worked through Jens Mikkelsen's excellent series on building a Sitecore site.  In his article on architecture, he makes an argument that the classic N-Tier approach of separate presentation, business, and data layers is not well suited to Sitecore development:

A Sitecore Magic Show

It's always worth catching the Joe Henriques show.  He can make a demo dazzle, and he makes a compelling case for Sitecore's engagement functionality.  Wednesday's tour de force at the New England Sitecore Users Group was no exception.  The head spins at the amount of information presented.

A Day in the TDD Zone

What makes a great day of test driven development?

1. A good plan.  This is going in my business layer, that is going in my data layer, and I'm not going to think about it just yet.  Let's wrap it in an interface and set it aside for a bit.
2. Good tools.  NUnit of course, and a good mock suite.  Moq was rocking for me--built around lambda expressions, it makes dynamically created objects obey intellisense.  Pretty nifty.  And ReSharper is wonderful, letting you define methods and classes in your tests, and then Alt-Enter them into existence.  Control-U+Control-U to rerun your last test, and a nice 100% code coverage report for the class under test when your done.

Looking at LINQ

I've been digging through the discussion of LINQ in the Albahari brothers' C# 4.0 in a Nutshell: The Definitive Reference, and it has cleared up a number of points for me:

1. At a compiler level, LINQ is a series of transformations done to expressions that begin with FROM and end with SELECT or GROUP BY.  These transformations turn free text queries into extension methods.  For example, var query = from A in aList select A.ToUpper() is transformed by the compiler into var query = aList.Select(a => a.ToUpper()). But, and this is a key point, the implementation of the methods is not determined.  You determine the implementation by the namespaces you include; you could write your own implementation of Select, Where, etc.  

Sitecore Data Reuse Talk

Here's my talk today on Sitecore data reuse options:

The slides can be viewed or downloaded here.

Sitecore Data Reuse Links

I will be presenting a talk on Data Reuse for the Sitecore Users Virtual Group tomorrow, Wednesday February 15 at Noon Eastern time. I'll be reviewing the options that Sitecore offers for data reuse: aliases, proxies, clones, wildcards, and pipeline handlers. I'll post a link to a video when it is available; in the meantime, I thought it would be useful to post the "Further Reading" links here:

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: