Extending Infrastructure Assemblies

Topics: CAB & Smart Client Software Factory
Aug 31, 2006 at 4:58 AM
originally posted by: atmchuck

While incorporating the Outlook Bar contributed by Matias Woloski (http://blogs.southworks.net/matiaswoloski), and getting some great guidance from John Askew, I found a need to modify some of the Infrastructure assemblies (Infrastructure.Interface and Infrastructure.Layout, so far.)

In particular, I've extended the WorkItemController to include a method for registering Outlook Bar items, so named, "RegisterOutlookBarLaunchPoint". This method (and the other "register" method from the Hands-On-Labs, are now in my descendant version of WorkItemController.

My questions to the forum are;
1) Is this a decent way to approach the registration for Outlook Bar items?
2) Should changes be kept out of Infrastructure, or made directly to the classes therein?

What I have is working OK for now, but any input on the approach is appreciated.
Aug 31, 2006 at 10:41 PM
originally posted by: askew

I think it is a good approach. I'd want to accomodate plug-in modules and allow them to register themselves and their views with the OutlookWorkspace. An Outlook style 'navigator' view over a set of detail views to show in the _rightWorkspace.

IWorkItemController only seems to need to expose 'Run' method for the Shell. Is that where you put the 'RegisterOutlookBarLaunchPoint' method or did you elevate it to the IWorkItemController interface?

I'd look at making 'OutlookBarWorkItemController : WorkItemController' and 'IOutlookBarWorkItemController : IWorkItemController' in the Infrastructure.Interface project for the Shell to be able to sense newly dropped in (and profilecatalog'ed) DLLs. The Shell would be modified through 'Infrastructure.Interface' to load a 'navigator' view, that launches _rightWorkspace views, from any module inheriting from IOutlookBarWorkItemController.

A benefit of seperating the OutlookBar support code from the generated Interface code is that you could regenerate a solution and drop your code in with VS from existing items.
Sep 6, 2006 at 6:37 AM
originally posted by: atmchuck

Thanks for the feedback, and sorry for the delay in responding. I'm oscillating back and forth between building demos on one hand, and building an architecture on the other!

I've currently got my own workitem controller (MyWorkItemController : WorkItemController). I did this, because I am able to implement the two methods I add in a generic fashion.

The other part of my original question revolves around the use of the Outlook Bar, and how to make it "all" generic. By that, I mean that I would like to have a module with a view that "plugs in" to the Outlook Bar. Then, additional modules that contain views that would "plug in" to the appropriate Outlook Module Bar item.

For example, using Outlook itself as an example, I might have a Module called, "Contacts" (contacts.dll), which contains the logic for populating the Outlook Bar, and the View that shows up in the upper portion of the Outlook Bar. I would then have additional Modules, "Contacts.ContactList", "SharedContacts", and "CustomizeContactView" (contacts.contactlist.dll, contacts.sahredcontacts.dll and contacts.customercontactview.dll, respectively).

My questions here are as follows;

1. Using this approach, I will quickly have a whole bunch of DLL's. Is this a bad thing? It would certainly make things highly customizable. But, I'm wondering about performance.

2. Is this the right approach for plugging in Outlook Bar views dynamically? I haven't yet built out this part yet (been focused on building/hacking demos<g>). I am still working through the messaging stuff with SCSF. So, any suggestions are appreciated.


Sep 6, 2006 at 7:40 AM
originally posted by: askew

I would consider putting all 'Customer' views in one module that knows how to register it's Outlook-view for navigation over the other views you listed -- those being the content on the _rightWorkspace.
Sep 6, 2006 at 7:51 AM
originally posted by: atmchuck

I did just that for the demo. But, I thought that I would be losing some of the "dynamic" configurability. I am still looking for ways to abstract what I have, so I'll be sure to drop more comments here as I progress. Thanks for the reply.