WorkItemController - What is it?

Topics: CAB & Smart Client Software Factory
Oct 7, 2006 at 4:25 AM
originally posted by: TrevStar22

What is the WorkItemController used for in the SCSF? In CAB I've been reading about using workitems and then when I switch over to building with SCSF, the automated tools don't build any workitems, just workitem controllers.

Could someone please explain... Do I need to build my own work items after the AddBusinessModule recipe completes, or is this some inherited behaviour of the WorkItemController?

Is all logic that would normally be in a workitem (like adding views) now the responsibility of the WorkItemController?
Oct 8, 2006 at 5:28 PM
originally posted by: headlam

A WorkItem typically behaves like an Application Controller. You can derive such a class directly from the WorkItem class or you can use the WorkItemController class. The WorkItemController approach is just a pattern for isolating your application controller functionality while still providing a standard protocol to initialize the application controller. To this end the WorkItemController extends the IWorkItemController interface. It is this interface that defines the protocol. The class you derive from WorkItemController is never instantiated directly. Instead it is passed as a generic parameter to the ControlledWorkItem<TController> : WorkItem class. Your WorkItemController derived class is the TContoller (generic parameter) in this case. Instantiation is usually in the Module class Load method, but can be done anywhere (i.e., ControlledWorkItem<ModuleController> workItem = _rootWorkItem.WorkItems.AddNew<ControlledWorkItem<ModuleController>>();). So in the end you do have WorkItem but how you extend the WorkItem is not by class derivation, rather you use a generic parameter to the ControlledWorkItem generic type. A neat approach and one that makes testing much easier. You can read more about this in the help files a swell. Hope this helps.

Module Controller Example (form SCSF)

public class ModuleController : WorkItemController
{
public override void Run()
{
AddServices();
ExtendMenu();
ExtendToolStrip();
AddViews();
}

private void AddServices()
{
//TODO: add services provided by the Module

private void ExtendMenu()
{
//TODO: add menu items here
}

private void ExtendToolStrip()
{
//TODO: add new items to the ToolStrip in the Shell
}

private void AddViews()
{
//TODO: create the Module views, add them to the WorkItem and show them
}
}
Oct 13, 2006 at 11:55 AM
originally posted by: TrevStar22

Thanks very much for taking the time to reply.

I'm not sure I understand the benefits of doing this, though. Isn't the initialization code of the work item being moved into a WorkItemController instead of into the WorkItem itself? It seems that the same process is happening, it's just happening through a generic instead of derived type.
Oct 17, 2006 at 4:24 AM
originally posted by: Mummas

I agree. It would be nice to know what added functionality/flexibility the Controller can provide over the WorkItem since the same functionality is in both.