Introduction

A good friend of mine says the sign of a good OO design is that you can describe the system in terms of 5 or 6 objects. TWiki isn't a good OO design, so it'll take a few more than 5 or 6! But I will try to describe them in a way that suggests the architectural vision for the core that drove the refactorings during Dakar development.

Overview of a TWiki request

Each request to TWiki is a completely separate program run. TWiki does not save state between requests, except in a small number of very limited cases (registration is the obvious one).

Each TWiki request is handled by an approriately named script, such as view or edit. These scripts are implemented as very thin (and almost identical) wrappers that simply create a singleton 'TWiki' object (our first class), and calling a method on this object. These top level methods on the TWiki object are held in the lib/TWiki/UI directory, and are coded as global functions. This is a coding convenience only; the top level procedures should be read as if they were methods on the top level TWiki object.

The methods in UI each print HTML output on STDOUT, which is written to the client.

What is the TWiki object?

The TWiki object is really just a container for a set of request-specific data. By keeping all global data under a singleton we are able to control allocation of release, and ensure we don't leak data between mod_perl invocations, an undesireable feature of earlier versions of TWiki.

The TWiki package also defines a number of globals that must be regarded as constants - they are never changed during a request. $TWiki::cfg, the hash that contains the configuration, is an excellent example of this.

The singleton TWiki object creates a number of other singleton objects under it. Each of these singletons relates to an area of TWiki functionality:

1. Access control - handles the permissions DB
2. Internationalisation - I18N and language support
3. Network access - interface to Net
4. Plugins control - manages plugins
5. Preferences - handles preference settings
6. Searching
7. Templates
8. Time
9. Sandbox - isolates TWiki from the underlying system commands

This subdivision is purely a coding convenience, and is driven by the need to map what was formerly global data into package local data. From an architectural perspective, these singletons are all tightly coupled, and should be regarded as part of the TWiki object.

Configurable static classes

A few singletons are designed to provide levels of plug-in configurability. They are still singletons, but their interfaces are designed to support alternative implementations. These are:

1. Store
2. Login manager
3. Password manager

The latter two can be selected from configure. Abstraction of Store is not yet complete.

"Proper" objects

The "proper" objects in the system are:

1. User - used to represent a user (login name, wikiname, email address etc), or group of users
2. Meta - represents the content of %META blocks in topic text.
   • this is the natural starting point for extension to a full TopicObjectModel
3. Form - used to represent a form definition
4. Plugin - used to interface to a single plugin. There is one Plugin for each plugin, if that makes sense! This is the natural base-class for an OO plugin.
5. Controlled file. The only existing implementation of Store has a second level of abstraction that supports a standard interface to conventional version control systems, such as RCS, CVS or Subversion. Three implementations of this lower layer exist, RcsWrap, RcsLite and Subversive. An object of these types is created for each controlled file.

More later.

-- CrawfordCurrie - 10 Nov 2005

I tried a logic architecture block diagram at BeijingArchitectureDiagram ...

-- MartinCleaver - 11 Nov 2005