History: SpidercoreDev

Here is some initial design work for a next generation of the TikiWiki core ( "2.0" would be a reasonable version to make the transition official). As the codebase grows it is important to see proper encapuslation so Tiki doesn't collapse under it's own weight - both in terms of performance and code maintainability. The design goal will be to strike a balance between OO design, and coding speed.

There have been many other proposals with a lot of great ideas. However, this proposal is intended to be much more evolutionary rather than revolutionary. A primary goal is to preserve as much as the existing Tiki code and infrastructure as possible instead of a large scale rewrite.

This core will:

• Maintain tiki's "keep it simple" philosophy and require only a modest amount of new code. A goal is to reuse nearly all existing code. In short, initial work will be a cut-n-paste job to get functions out of the bloated lib files and into a properly encapsulated classes framework (e.g. so 'create_page' does not get parsed when reading a forum post, etc.)
• Focused on scalability for both feature depth and speed. Some sites want a lot of features, and others want less features a more speed because of traffic demands. The core should be scalable, much like the Linux kernel, where new functionality can be added or removed where desired. Unused functionality should not even be parsed.
• Core functionality will be much more Object Oriented and have greater use of inheritance (extend). The reduces code and makes extending Tiki infastructure for your own specialized purposes much easier.

The migration will be done in a few key areas first (wiki pages will be the first to move). This will prototype the design and allow several development cycles to happen to ensure a proper design. When complete, classes like TikiLib or WikiLib will be deprecated and only kept for legacy features.

Some detail:

A new class structure is defined from which all Tiki classes inherit. The existing lib/* directory structure will be maintiained, and all existing libs can stay in place as migration takes place. The basic class inheritance looks like:

• class TikiFeature - Cool feature such as Wiki or Blog or Article, etc...
• --> class TikiContent - Virtual Base class upon which all "content" oriented classes derive (wiki, article, etc. )
• ----> class TikiBase - a few utility functions common to every Tiki class
• --> class TikiDB - little changed from current core

An instantiated class should typically represent a single object, such as a wiki page or article. Aggregate data functions are currently in the same class. Perhaps a derived TikiFeatureGroup class might be designed, but this is uncertain for now.

A few rules of thumb:

1. There should be _NO_ presentation code (no smarty assignments, no html generation, etc) in any class derived from TikiBase. Two notable exceptions might be extreme error conditions or convenient $rs->GetMenu() calls
2. All derived class should support a core set of methods. In real OO land, there would be several pure virtual functions named: load, store, verify, expunge (delete has a naming conflict with native php function). These functions should always follow these names so derived classes can properly call into base methods

Example: imaginary TikiFeature derived class, see TikiPage for real example

class TikiFeature extends TikiBase
{
// member var that hold corresponding data
var mRow;

function TikiFeature( $iFeatureID = NULL ) {
// be sure to call base constructor!!!
TikiBase::TikiBase();
$this->mFeatureID = $iFeatureID;
}

function load() {
if( $this->mFeatureID ) {
$this->mRow = {... select data from db where feature_id=$this->mFeatureID ...}
}
return( count( $this->mErrors ) == 0 );
}

// This verifies data integrity. NOTE: pass by reference is crucial, because
// some modifications might be necessary (length truncation, etc.);
function verify( &$inParams ) {
// clean up variables
foreach( array_keys($inParams) as $key ) {
$inParams[$key] = trim( $inParams[$key] );
}

if( empty( $inParams['required_column'] ) ) {
$this->mErrors['required_column'] = SOME_ERROR_MESSAGE;
} elseif( strlen( $inParams['required_column'] ) > FEATURE_LENGTH ) {
$inParams['required_column'] = substring( $inParams['required_column'],
0, FEATURE_LENGTH );
}

{... continue testing hash values various conditions ...}

return( count( $this->mErrors ) == 0 );
}

// this method stores the data.
function store( &$inParams ) {
// ALWAYS call our verify first to ensure data is safe to go into db
if( $this->verify( $inParams ) ) {
$this->mDB->StartTrans();
if( data exists ) {
{... update existing rows ...}
} else {
{... insert new row ...}
}
$this->mDB->CompleteTrans();
}
return( count( $this->mErrors ) == 0 );
}

funciton expunge() {
{... delete appropriate rows for this feature in all necessary tables ...}
return( count( $this->mErrors ) == 0 );
}
}
cvs checkin coming soon. Trying to stay out of the way for a stable 1.8 drop before big changes go in...