If we all worked on the assumption that what is accepted as true really was true, there would be little hope of advance.

–Orville Wright

How different would all our lives be if Mr. Wright hadn’t challenged assumptions about the possibility of flight?


I just downloaded the latest version of the Castle MonoRail assemblies.  For a while, I have been wary of using the Scaffolding for controller and View because the views seem to stumble over nullable data types in the Model classes.  While that seem to still be a problem (maybe I’ll write a patch for it), I have started to use Scaffolding for the controllers and the customizing the Views.

Here are a list of the parameters available in the PropertyBag along with the names of the files you should create.  I’m using NVelocity, so my views end with the .VM extension.

List View

View Name: List.vm
$Items : a listing of all the records for the given model

New View

This is the view that collects information for a new record.  The form action should point to the Create controller action.

View Name: new{classname}.vm  (e.g.: if you have a model called Study, your view name will be newStudy.vm)
${classname} : is the item that you’re editing.

When creating for elements, you should name them with the format name=”classname.propertyname” (e.g.: for the Study model, if I have a property called Name, then I should add a form element with the name “Study.Name”.

Create View

There is none… this controller action just redirects to the list view after the new record is created.

Edit View

View Name: edit.vm
Query String:
id : the primary key of the record (I’m not sure what happens with models using composite keys)
The form elements have the same name format as the Create view, which is name=”classname.propertyname”.

[I’m still working to gather information on the child collection properties and the available options for those collections]

Confirm View

This is the delete confirmation view.  I usually use the JavaScript ‘confirm’ method and the do a redirect to the delete action.

View Name: confirm.vm
$classname : the record to delete
id: the primary key of the record to delete.

Remove View

There is no view for this action.  The controller just redirects to the list view.

Over the past few months, I have been designing a system which integrates with a number of database servers (7 within a single application) across several different schema types (3 in a single application).  I have also started to see the value in writing good unit tests as connecting to a live database usually cannot give you the correct data for a good test.

The Object Mother Design Pattern

I have found that using the Object Mother design pattern to create the model objects that I use inside a test has decrease the number of lines I have to write for a realistic unit test.  Essentially, the object mother is a class with several static functions used to create object.  Using this class to create your objects means that the code inside you unit test function can focus on the actual testing.  Martin Fowler has a good overview of the Object Mother Design Pattern and Peter Schuh and Stephanie Punke have also written a nice paper on the pattern as well.

Person Class UML

Person Class

Person Mother Class

You can then use the PersonMother class like so:

Person newPerson = PersonMother.Create();newPerson.FirstName = "John";newPerson.LastName = "Doe";newPerson.Save();

This is all fine and good, but what if you need to customize your object once you’re object mother has returned the object to you?  Maybe we want to automatically set the person’s name to “John Doe” in our create method, but what if we want to add some children?  What if in some cases, we don’t want to have the returned Person object to have any Children in the collection.  Then you’re back to having a complex unit test again where more lines (and screen real estate)  is dedicated to the object rather than the test.

Note that if your domain model is such that a few more static methods on the Mother class will do, then you’re probably fine with the basic ObjectMother pattern.  However, if your domain model is complex and you need to test any number of model permutations very easily, then method chaining may help.

Enter the Object Mother with Method Chaining

The concept here is to create a single method in the Object Mother called Create() which takes no parameters and returns a valid instance of the Object Mother Class.  This means that if the object is persisted to the database right after the object mother returns, the database shouldn’t throw any validation errors.

BaseMother Generic Class

The concrete Object Mother class then has a series of methods which return an instance of the Object Mother.

In this way, methods can be executed in a chained manner, reducing the number of lines used to create and customize the object.  An added benefit is that dependent objects can be assembled by another Object Mother class and the passed into a method on the parent object’s mother class.

PersonMother Class with Method Chaining. The Create method is static here.

Using .Net generics, we can create a base Object Mother class which can make the implementation of concrete Object Mother Classes much easier.

Person newPerson = PersonMother.Create()    .SetName("John")    .AddChild(PersonMother.Create().SetName("Johnny").Value))    .Value;newPerson.Save();

Note that all that code can be on one line.  I’ve just expanded it to make it easier to read in this format.

In my most recent project, I have been using ActiveRecord as my ORM.  I created a subclassed ObjectMother class, allowing me to perform database operations as part of the method chain.  This is especially useful when object persistence has to occur is a certain order (of courses, defining a proper cascade within the BelongsTo attribute can also help with this… this is just an example).

ARBaseMother Class with Method Chaining

I have a few other methods on the ARBaseMother to help with my ActiveRecord testing.

Person Mother AR Class with Method Chaining

Now, the example again:

Person newPerson = PersonMother.Create()    .SetName("John")    .AddChild(PersonMother.Create().SetName("Johnny").Save().Value)    .Save()    .Value;newPerson.Save();

I have found that this pattern makes writing unit tests much easier… which means that I might actually write more of them!

Do you have an pattern which help you write tests?  Please share them in the comments below.

For a solid month, I had all sorts of problems with my Apple Airport, especially when it came to using a connected USB hard drive with Time  Machine.  I found that downgrading to firmware version 7.3.1 gave me connection stability for the USB drive connected to the basestation and it allowed me to use the drive with Time Machine.

After searching through my MacBook’s disk, I finally found the Airport Extreme Base Station Firmware 7.3.1.  There has been some lively discussion about this topic on the Apple Support site.  Please note that some people experienced settings problems after reverting to version 7.3.1.

Wow, it has been a really long time since I last posted on this blog.  Surprisingly, I’m still getting quite a few hits on a number of blog posts, though.

Here’s a quick update on what’s going on with me:

My wife and I have a new addition to our family!  Woohoo!  That’s probably one of the big reasons I haven’t really been paying much attention to this blog lately.  Our daughter, Fiona, is a wonderful little girl.  She’s spunky like her mom… which is going to be trouble sooner or later!

Professionally, I’ve shifted gears a little bit in the last 9 months.  I’m no longer focusing on SharePoint, but am now working with a few well-known open source projects.  Among them are MonoRail and ActiveRecord from Castle Project.  Working with ActiveRecord means that I’m now using NHibernate as an object-relational model.  I’ve been using NVelocity for web site templating, Scriptaculous for animations and PrototypeJS because it’s incredibly useful.  I’m back to using TestDriven.net for unit testing, CruiseControl for continuous build integration, and NAnt for build scripts and other automated functionality.

Hopefully, I’ll start blogging about some of these technologies I’ve been using.  If nothing else, posts can serve to remind me of trouble spots I’ve run into and how I fixed certain problems.

Peace and Blessings to you!

I’ve recently had a need to model a looping workflow with a SharePoint Designer workflow.  Designer doesn’t have a ‘Start Workflow’ action available by default, so I installed the Useful SharePoint Designer Workflow Activities on Codeplex.

My workflow would be designed like this

  1. Collect Data From Users with Task Form
  2. Set Workflow Variable to Step 1 Task ID
  3. Check for repeat condition on Above Task
    1. Start a new instance of this workflow
  4. (Workflow Done)

Looks great, but when running this workflow, I kept getting the following error:

Exception from HRESULT: 0x8102009B

at Microsoft.SharePoint.Library.SPRequest.AddWorkflowToListItem(String bstrUrl, String bstrListName, Int32 lItemID, Int32 lItemLevel, Int32 lItemVersion, Guid workflowPackageId, Guid& pWorkflowInstanceId, Guid workflowTaskListId, String bstrStatusFieldInternalName, Int32 lAuthorId)

I searched around and found out that you cannot start an instance of a workflow on an item when the same workflow is already running on that item.  Lucy’s blog had a code sample which checked the target item for the duplicate WF and removed the WF if it was found.  I wanted to keep the data from the first workflow, and this would remove it.  Not exactly what I wanted.

Here’s a simpler approach I took:

Modify the original workflow (Workflow A)…

  1. Collect Data From Users with Task Form
  2. Set Workflow Variable to Step 1 Task ID
    1. Check for repeat condition on Above Task
    2. Start a new instance of the LookBack workflow
    3. Stop this workflow and log the message ‘Completed – Looping’
  3. (Workflow Done)

Create a second workflow called ‘LoopBack’:

  1. Pause for 1 minute
  2. Start a new instance of Workflow A
  3. (Workflow Done)

I can start an instance of LoopBack at the same time as Workflow A.  Then, LoopBack waits while Workflow A completes.  After that, it starts Workflow A over again.  The pause is there since Workflow A takes some time to fully complete.

Note, if you’re not running SP1, the Pause for 1 minute step will take 30 minutes to complete.  Installing SP1 will fix this issue.

This is a really simple way to model a looping workflow without going into Visual Studio.

Fahrenheit 451, by Ray Bradbury

Everyone must leave something behind when he dies, my grandfather said.  A child or a book or a painting or a house or a wall built or a pair of shoes made.  Or a garden planted.  Something your hand touched some way so your soul has somewhere to go when you die, and when people look at that tree or that flower you planted, you’re there.  It doesn’t matter what you do, he said, so long as you change something from the way it was before you touched it into something that’s like you after you take your hands away.  The difference between the man who just cuts lawns and a real gardener is in the touching, he said.  The lawn cutter might just as well not have been there at all; the gardener will be there a lifetime.