Summary of PrefsDotPm Refactoring

I've refactored PrefsDotPm recently, to make it more modular and also more compatible with the idea of caching preference data under ModPerl or SpeedyCGI.

The New PrefsDotPm Architechure

The new architecture looks like this:

TWiki::Prefs::TopicPrefs

The TopicPrefs class is the repository for preferences settings associated with a particular topic. It only holds settings defined specifically in that topic, and handles all reading and interpreting of such settings.

Currently, it handles both standard Set syntax, as well as settings defined with UsingFormsForSettings. It also reads all form data into the preferences store with a prefix of FORM_.

If we decide to change how preferences are stored or defined in the future, this class will ideally be the only one that needs changing.

TWiki::Prefs::PrefsCache

This subpackage serves two functions: it holds a cache of TopicPrefs objects for each topic whose preferences were needed, and it also acts as a class to manage the way that preferences cascade from TWikiPreferences through WebPreferences on down to the individual user and topic preferences.

TWiki::Prefs

The "parent" package provides a "legacy" interface to the rest of the TWiki code, implementing all the old public methods in terms of the above classes.

Still To Do

• Currently, there is a global method getPrefsFromTopic that reads in some random topic's preferences and throws them in the current request's global preferences cache, overriding any non-final existing settings. It is used mainly for loading plugin settings. I think that the code for deciding which topics hold a plugin's preferences should be reworked and put in the PrefsDotPm module. In turn, this method should go away. Any other use of it needs to be given its own consideration for adding to the module.
• Also, at the moment I'm not sure how to handle topic-level preferences in INCLUDE's. E.g. if one topic includes another, should the preferences be carried over to the including topic? If not, should they still apply within the scope of that particular include (so that at least the include renders the same as in would alone)? This may be related to RefactorCommonTags. Look at PreferencesTest1 and PreferencesTest2 to see what I mean.

-- WalterMundt - 23 Feb 2004