Browse Prior Art Database

Attribute-driven application/user settings using code reflection

IP.com Disclosure Number: IPCOM000178351D
Original Publication Date: 2009-Jan-23
Included in the Prior Art Database: 2009-Jan-23
Document File: 8 page(s) / 94K

Publishing Venue

IBM

Abstract

This article introduces the concept of using code reflection to simplify the design and implementation of settings (per-user or system-wide) in applications. We do this by associating metadata to member variables in program code with custom attributes. These custom attributes are used during self-reflection to determine how data is loaded or stored, with optional parameters allowing special conditions to be taken into account. Collectively, this concept separates business logic from the mechanical workings, and can be easily expanded to accomodate the needs of the application.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 1 of 8

Attribute-driven application/user settings using code reflection

Disclosed is a technique for associating metadata to program variables and by using reflection automate the task of preserving and restoring application settings with minimal supporting code or difficult to use (restrictive) class libraries.

    Applications may begin their product life with a small handful of user settings, but over time, these can easily increase to large numbers depending on the complexity of the software. Consider early first generation word processors, in comparison to modern day equivalents which now typically offer over 100/150 different settings, and more when customizable menus, keyboard shortcuts, toolbars, and other extendable features are taken into account. The complexity, and share number of settings involved greatly increases the possibility of software defects which also brings additional testing and maintenance overheads. With this mind, it would not be uncommon to say applications invariably start their product life with little consideration to supporting large numbers of application settings, and after all if these early versions only have a handful of options, why would you over engineer things?

    Applications invariably load/store program settings in a system registry or configuration file. Each of these application settings requires programmatically reading/writing values to/from a persistent store, handling error situations and making decisions when settings are missing, such as when the application is used for the first time, upgraded, dealing with corruption, or other scenarios.

To give an idea what's involved; lets consider the steps to read a single value from the Microsoft Windows* system registry:
1. Open the required sub key (HKLM

\company

2. Check the key was successfully opened
3. Read the values of the items required (name/value pairs)
4. Handle missing values by substituting default values
5. Close the registry


In larger applications, its easy to see how business logic can easily become

lost in these implementation details, and the complexities can become exponential with higher numbers of application settings.

Known solutions to this problem are:
• Hand coding
• Consolidated option classes to handle all reading/writing operations
In the first instance, this is probably where all applications start - with a small

number of persisted settings, hand coding of each setting would at first seem no big deal. Of course, this approach becomes costly when more than a handful of settings are required.

    The second approach is also disadvantaged by high maintenance costs and tends to be tightly coupled to the application so re-usability becomes a problem. It would also be overkill to use this approach if you only have a small number of application settings.

    The main concept presented in this article is to use metadata to describe how data fields within a program are mapped to registry entries. Cust...