Our best friends and our worst enemies are our thoughts.  A thought can do us more good than a doctor or a banker or a faithful friend.  It can also do us more harm than a brick.

–Frank Crane

How true this is!  How many times have I been prevented from doing something simply because of a doubtful or fearful thought?  How powerful and empowering are ‘true’ and ‘right’ thoughts about our self and others!

Men spend their lives in anticipation, in determining to be vastly happy at some period when they have time.  But the present time has one advantage over every other — it is our own.  Past opportunities are gone, future have not come.

–Charles C. Colton

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?

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
QueryString:
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.

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

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.

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.

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!

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: 0×8102009B

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.

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.