Item4795: Refactoring Store to enable non-file based topic stores, and to make multiple stores possible.

its a little ew in there

-- TWiki:Main/SvenDowideit - 11 Oct 2007

Too darned right. And the first step is to decouple the core from the store by using Foswiki::Meta as a proper store object. i did this work back in early 2008, but never checked in because of the February TWiki summit.

The changes are invisible to users of Foswiki; and further, they are invisible to extensions authors who have used the APIs, though some testcases have had to be rewritten. The following is written for core developers only.

Here's a summary:

Foswiki::Meta is now a "handle" to a store element. A store element may be a topic, a web, or the root of repository. You create a new handle for a topic using $topicObject = Foswiki::Meta->new($session, $web, $topic). At first the new object is just a stub; the topic isn't loaded until you (1) call a function such as text() which loads the topic from the store (if it exists) (2) explicitly load a revision of the topic by calling $topicObject->reload(). You can create a new stub and load it in one move using $topicObject = Foswiki::Meta->load($session, $web, $topic). Most of the methods that you would have previously called on {store} are now invoked on a handle. Attachments and forms do not have their own store handles; it would have been stretching the point too far at this stage.

Use of {store} has been driven out of most code modules except Foswiki::Meta and Foswiki. All other modules should use the Meta object.

The store itself has been refactored to make the Foswiki::Store class an interface (pure virtual base class in C++ terms). A subclass, Foswiki::Store::VCStore, inherits the responsibilities of the old Foswiki::Store class. Foswiki::Store::VCStore is a factory class that works with Foswiki::Store::VCHandler. Foswiki::Store::VCHandler= is extended by Foswiki::Store::RcsLiteHandler= and Foswiki::Store::RcsWrapHandler (c.f. old RcsFile, RcsWrap and RcsLite). In this way the various store layers are decoupled, making it much, much easier to plug in an alternate store implementation.

I finally bit the bullet and rationalised the getRevisionInfo problem, where callers had to know whether to recover revision info from the meta object, or from the store.

I refactored the Prefs to much cleaner code. One effect of this is that there are fewer methods exposed, and most preferences are recovered using a simple getPreference call on the $topicObject (or $webObject), and %SESSION_TAGS no longer exists (phew).

The expansion of macros and the rendering of TML are no longer invoked via the singletons. Instead they are invoked via the object, for example, $this->{session}->handleCommonTags($text, $web, $topic) is now called using $topicObject->expandMacros($text) and $this->{session}->renderer->getRenderedVersion($text, $topic, $web) becomes $topicObject->renderTML($text)=

Macro expansion methods are now passed a topic object rather than web, topic. The interface to tag handlers registered by plugins remains unchanged.

Related topics; MultiStoreRefactor suddenly becomes much more credible.

Broke out the rename functionality from Manage.pm, and the password management from Register.pm

-- CrawfordCurrie - 08 Mar 2009

Phase one complete. Next, we need to clean up the interface to the search and query algorithms, so that they are passed enough information to do an intelligent optimisation.

-- CrawfordCurrie - 10 Mar 2009

Fixed MANIFEST according to your re-factoring, so I could test my BuildContrib modifications.

-- OlivierRaginel - 26 Mar 2009

Item1370 for the search&query cleaning I'm doing

-- SvenDowideit - 27 Mar 2009

waiting for release 1.1 - any new issues should have their own task.

-- SvenDowideit - 30 May 2010