Fields Owned By Region

Proposal: Fields Owned By Each Region

_NOTE_ This proposal replaces my previous Single Field List proposal, which I now view as inelegant and limiting.

I propose that there be a computed field manager in each region, instead of the current single global manager we have now; this will be inexorably linked to the FE_region over which its finite element fields are defined in that region. We can consider Computed fields as the true fields in Cmgui and relegate FE_fields to being an implementation detail. A region thus becomes a container for field definitions of any type.

Note that groups will continue to exist as subsets of the FE_region sharing the same field manager. In future I also anticipate allowing multiple instances of field representations (field manager + FE_region) in separate Cmiss_regions.

Implementation Issues

Plenty to sort out here, but want to get the proposal on the page.

• Computed field package in each region requires some global information for defining certain field types, e.g. graphics_window_manager, curve_manager, time_keeper. Current APIs for creating Cmiss_regions do not pass any arguments in, so need mechanism to get such data into new child regions, possibly the "viral" spread of objects I have separately proposed for selections and graphics.
• Many issues with data encapsulation. For example, only FE-related fields should know about FE_region.

Migration Steps

• Graphical Element Editor field choosers need to work with the computed field manager for the current region. Similarly for their commands.
• Migrate "gfx define field ..." to "gfx region PATH define field ...". Existing "gfx define field ..." commands can work with a default region stored in the command data, initially "/" but changeable by the user.

Benefits

• Solve region time awareness issues in http://www.cmiss.org/cmgui/tracker/463
• Avoids issues of caching element field values from multiple regions.

Other Issues

• Will leave for later linking of equivalent fields up and down the hierarchy.
• Embedding.

Your input is welcome.