First impression of CAB

Topics: CAB & Smart Client Software Factory
Feb 17, 2006 at 4:16 AM
originally posted by: Rdunzl


I have just finshed reading the documentation on CAB and I've also worked through the walkthrough quickstart which proved to be a bit of a challenge to me.

First of all I can't praise you ppl that makes CAB and the other application blocks available enough. The application blocks are just great to use and to learn from.

During the walkthrough I came up with a few issues that I thought I would address here:

1. The id parameter of WorkItem.WorkSpaces is case sensitive. Since I'm usually coding in VB I'm that used to case sensitivity, and I usually converts strings to lower case before comparison when I implement similar methods (even though my strings are always pascal cased). This prevents errors in case of case typing errors. I think this ought to be a "best practice". If SQL and VB can do without case sensitivity then most hardcoded string identifier scenarios probably can too. If you choose to keep the case sensitivity, then pls. make notes about it in the walkthroughs, since this is (imho) an important issue, especially for VB developers.

2. I guess that the walkthrough documentation has not been completed yet, but I'd like to comment it any way (not mentioning all of the missing stuff).

2.a. The sample code should resemble exactly what you get when you use VS to step through it. There should be no unneccesary import/using statements, and the form's designer generated code should not be changed. If you choose to genreate forms using other code template tools then it should be stated in the walkthrough that some stuff is different from what you'd expect.

2.b. Make assumptions about the target audience. If someone wants to dig in to CAB, then I think it's safe to assume that the person knowns how to create a class. These assumptions helps the walkthrough documentation to be more clear. Instead of writing "right click the project folder in the solution explorer", "click add..." etc. make simple statements like "create a class named ShellApplication in the shellapplication project".
Begin the walkthrough by stating prerequisites like "Before you begin this walkthrough you have to be familiar with creating classes and creating and implementing interfaces". Maybe add references to MSDN if you want to be nice.

2.c. For the control's properties I think it could be nice if you showed these in tables like it's done in many books from Microsoft Press and in some of the how-to's/walkthroughs in MSDN. Then you can write "add a form/usercontrol/whatever to the project", "add a splitcontainer to the form, and a TabWorkspace to the left panel in the split container", "configure the control's properties as shown in the table below" and then follows a table with three columns, one for the control's name, one for the (non-default property) and one for the property's value. Don't change properties unless it's important (like changing a user control's size to 250x250 if it's going to be Dock.Fill'ed).

3. From an educational perspective it's a "best practice" to begin each lesson by a brief explanation of what has been going on until now ("In the previous stages we have done this and that"), What we're going to do in this lesson (on this stage), and why we are doing it. This helps the student to keep an overview of what's going on.