Item5235: Major refactoring for object orientation

Part One

Those of us working in the core are often faced with horrible problems due to the layering of hacks, especially those related to web, topic and meta parameters being passed separately to functions. What is really needed is a proper "topic object" that encapsulates the web and topic. We've been working slowly towards this since TWiki 4.0, and now is the time to complete the refactoring. It is basically to support this refactoring that many of the tests have been developed.

Part Two

In the past the TWiki core has assumed the TWiki database implementation (files on disc with embedded meta-data) which has been a major constraint to scalabiity and performance. Sven and I have been working steadily to eliminate this, and encapsulate the store. Now is the time to complete the encapsulation - at least as far as we can without breaking any extensions.

The goal is to achieve total separation of TWiki::Store from all the other core modules except TWiki::Meta and TWiki. TWiki::Store will be recast as an purely abstract class (interface). The RCS-specific store implementation will be pushed down to be an implementation of this interface. Initially the refactoring of this implementation will be kept to a minimum, but in future it may make sense to eliminate the handler architecture of the RcsFile-derived classes.

Impact

None of this will have any impact on those extensions authors who have observed calling standards (most of them, since we started enforcing the APIs), and it should not have any impact on end users either. It is a totally internal refactoring. The major future benefit is that it will allow us to open up a new, object-oriented API into the core via the TWiki::Meta object. The performance impacts should be minimal, as any loss due to object creation should be offset by the gains achieved through code simplification.Initial work has already identified and eliminated several bugs and bad code segments that arose due to the confusion of having so many parameters flying around.

Benefit

The main benefits are:

• Significantly simpler core code
• Elimination (or at least isolation) of some ambiguities in the core (e.g. "where does revision information come from")
• Encapsulation of the store interfaces for future performance improvements
• Simplification of access control testing
• Reduction in repeated topic reads
• Internal topic/web object model, which simplifies TOM

This is an important and long-overdue refactoring. The work will initially be done on a branch, mainly to allow us to do the work without risking 4.2.0 in any way.

BTW before anyone starts slagging me off for doing this when I "should have been testing 4.2", I will point out that I have uncovered more bugs in 4.2 doing this than I ever would have just through simple user testing, as I have been pushing the corner cases.

- TWiki:Main/CrawfordCurrie - 10 Jan 2008

Work abandoned due to lack of motivation since developer summit.

-- CrawfordCurrie - 05 Apr 2008