Accessing Information

Levels of Information

As we have separated information inherent to data from data related to a specific PC, we have had more ability to separate out information and keep it at the level where it is defined. To do that, we now end up accessing information within different scopes.

Game Mode

Some information is set in the Game Mode, and we store/access that information by Game Mode. Game Modes are loaded once when PCGen is booted, and not reloaded. Therefore, this information is generally static/persistent information.

Data Set

When a set of campaigns is loaded by a user (or implied by opening a specific PC), we call that set of Campaigns a "Data Set". Many items (list of available Races, Languages, etc.) are inherent to the Data Set. Much of this information will need to make its way out to the UI to be displayed to the user. For the most part, this information is stored today in the LoadContext and its children.

Player Character

When a PC is created, there is a set of information related to the PC. This information is stored in various places, but in general it is stored within the Facets and new formula system. More detail is available in Adding items to the PC.

Architectural Musings

This is one of the areas where the default design methodology of Dependency Injection (DI) doesn't work well if you consider the base design of a DI system (pre-wiring objects). While the Facets themselves today are static, MANY of them are dependent upon assumptions about the data we load, and the fact that many of our game systems are d20 systems. Some of them are idle Facets (and thus shouldn't have been loaded under ideal circumstances) for non-d20 systems. This area needs some help.

There are also aspects of DI systems that are highly interesting given the different scopes of information shown above. The ability to define an information "scope" (in the case of Spring an org.springframework.beans.factory.config.Scope), is definitely along the lines of what would help keep information loadable one time while "guaranteeing" that the scopes of information cannot leak. This would be of significant benefit to a desire to load multiple systems or multiple PCs at the same time without the significant complexity we currently bear from that situation.

After having read through how the HTTP (request/session) scopes work in Spring, I find it highly intriguing to implement a similar design. My primary concern is that I'm not sure anyone currently active really understands the multiple threads generated by the UI, which could cause a significant amount of damage if not handled correctly.

More on this later...