Log in

No account? Create an account

November 18th, 2012

fedora 蓝色小药丸


Since 2009 I started working on the Presentation Studio software product, which is part of Morningstar Direct platform. It has been 4 years! Coincidentally it is also the time period I took the CFA exam (from July 2009 to September of this year). The application is rather complex now, but not hard to understand if one find the pattern. And "scope" is such a pattern.

The software is based on Microsoft .NET technology, namely WPF, which provides several kinds of scopes already. The first is focus scope, means within which there is a focus. The other is an command scope, which means the element that registered command handlers would handle the command. Similarly there is an event scope, because routed events are bubbled upwards and downwards.

Then we added similar structures in our program. A focus scope is named "selected object", for example. A component (either chart or table) has its own selected object. The designer tracks selected component. A command scope is created within every component, handles a few commands. A setting scope existed since the beginning: for any component settings that user is not explicitly set, there is always a fallback/default value; but when the value is set, then future operations will use fallback/default values. The undo/redo operation can also be considered inside a scope.

A scope can be defined as a one to many relationship. And the interactions are 1. get; 2. set; 3. being notified about changes. The purpose of scope is to allow multiple "one to many" relationships within the application. For example, it would be rather incovenient if there is only one focused element per application, so focus scope is created -- as long as visual tree fragments are in different focus scopes, they can each contains a focused element. This very natual for objects organized into a tree.

Another use of scope is to simplify/eliminate the path of objects, provide a well behaving, easy to use object.

To verify if a scope is correctly defined and used, see if above requirements are met: can every object in the scope can get and set subject resource? Can every object receive notification if subject resource changes? Of course the focus scope is not well defined, since "GotFocus/LostFocus" events are usually random.

The outliers are scopes defined on the fly, broken the boundaries of different scopes. Disable related scopes before using the newly created one.

edit: 1. forget to mention that DataContext is the single most important scope in WPF; 2. the subject resource must be referenced through scope object, so the point is to locate related scope object easily.
fedora 蓝色小药丸

My tweets