text: Cider Item Creation
  
  In Windows Forms, there were many occasions when you wanted to separate out your design time code from your runtime code. For design time code you didn't want to execute at runtime, you would use a designer and for runtime code you didn't want to execute at design time (i.e. it did a bunch of database access) in most situations you could use the Control.DesignMode property.
  
  The problem with Control.DesignMode was that it depended on IComponent.Site being set for your control. Unfortunately, there were cases when this wasn't true, most noteably in the constructor of that control.
  
  If you've seen Brian Pepin's articles on the Cider designer (part 1 here and part 2 here) you'll know that in Cider, we've gone away from IComponent. This means that there isn't a Control.DesignMode property for WPF/Avalon controls.
  
  Instead, Cider's Extension architecture (again see Brian's articles) is used to add a CustomInstanceFactory to a control. When Cider goes to instantiate that control, instead of calling "new" or "Activator.CreateInstance" it calls its CustomInstanceFactory instead.
  
  In other words, at design time, if there is a Custom Instance Factory attached to an object, it is used to instantiate the object instead of the designer itself. This extensibility point allows you to set a bool indicating that you are in design mode (as the sample code above shows) and do any other design time specific code.
  
  In fact, you could even return a design time specific instance of your control. As an example, Cider currently uses this mechanism to provide our own design time version of Window since we can't use a real Window instance as it cannot be parented to another control.
  
  To summarize: Custom Instance Factories provide the ability to hook into the creation of your control at design time.