General Rules for using Items and State

Topics: CAB & Smart Client Software Factory
Jun 6, 2006 at 9:18 AM
originally posted by: yysun

What is the general rules of using

- RootWorkItem.Items
- ParentWorkItem.Items
- ParentWorkItem.State
Nov 28, 2006 at 11:33 AM
originally posted by: mlemon

I think you are looking at a free disposed community to make whatever they want out of "Smart" client in the OO & design patterns realm. Smart Client as it is loosely termed incorporates the be all and end all thinking. Pre-supposedly.

MVP - I agree with. It is the same as using frames in Delphi conceptually wise. Domain logic, I agree with. General infrastructure logging & security & caching, I agree with. Easily maintainable web services, I agree with. ADO .NET2 disconnected datasets either strongly typed or not, I agree with. It is all in there.

The arguement I am trying to find is perhaps is ... best principles, project, future technology changes? Hence I am here in one place looking at the "Seperation Of Concerns". Maybe I'll stick with what I know best. Not so RAD but RAD.

There is ground to establish in thinking about the "Separation of Concerns". Which most experienced programmers should be able to handle, quite easily in a RAD environment.

The problem I find with Smart Client. Yes there is a learning steep learning curve (hurdle). Which I think is worth hurdling just to pick up on design practices.

But at times I think there should be a mini IDE upon the IDE to conform to the patterns. Hence GAT & GAX which is a little bit dicey, when you have to deal with a common XML recipe file and regedt32 out some keys with an uninstall.

Good job that we are Gobally Unique perhaps?

The establishment between patterns & practices is too fluid.

But I think SC-SF will be established in the not too distant future. It is about value of community feedback. I expect you have not found much value in my response.

Your question may lead to the answer. HOL.
Dec 5, 2006 at 9:18 AM
originally posted by: rayn

A WorkItem should be thought of as a scoping container. A child WorkItem can easily see its ParentWorkItem and the RootWorkItem.

The Items Collection contains all objects within a given WorkItem.

So I would say that, as a general rule, you would store "global" objects in your RootWorkItem and any other objects that your child WorkItem might need in the parent WorkItem.

To give you an example, we're injecting SmartParts into our RootWorkItem when our Busines Modules load. When the user launches an event that requires that SmartPart to be shown, our code looks in the RootWorkItem for that Smart Part and then displays it on a Workspace in the shell.

This may not be the route you want to take, but it does work very well for us.

We haven't coded anything using the Parent WorkItem, but if you look in WorkspaceLocatorService.cs in the Infrastructure.Library project, there's a good example there. It looks in the WorkItem passed for a particular SmartPart. If that SmartPart isn't found, it looks in its ParentWorkItem for that smart part. This pattern continues till it either returns the WorkItem containing that SmartPart or it returns null.

As far as WorkItem state is concerned, we're not using that at all. From what I understand though, you should think of State as something more on the backend using web services.

Hope that helps.