History of ClassStructure
Some detail:
All bitweaver classes follow the same structure. The basic class inheritance looks like:
* class BitFeature - Cool feature such as Wiki or Blog or Article, etc...
* --> class LibertyAttachable - Virtual Base class which adds handling of ((LibertyAttachments|attached files and resources)).
* ----> class LibertyContent - Virtual Base class upon which all "((LibertyPackage|content))" oriented classes derive (wiki, article, etc. )
* ------> class BitBase - a few utility functions common to every Bit class, and includes member variable mDb, a shared BitDb database object for all objects derived from BitBase.
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 BitFeatureGroup class might be designed, but this is uncertain for now.
A few rules of thumb:
# There should be _NO_ presentation code (no smarty assignments, no html generation, etc) in any class derived from BitBase. Two notable exceptions might be extreme error conditions or convenient $rs->GetMenu() calls
# 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 BitFeature derived class, see BitPage for real example
{code in="php"}
class BitFeature extends BitBase
{
// member var that hold corresponding data
var mRow;
function BitFeature( $iFeatureID = NULL ) {
// be sure to call base constructor!!!
BitBase::BitBase();
$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( $inParams as $key => $value ) {
$inParams[$key] = trim( $value );
}
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;
}
}
{code}
All bitweaver classes follow the same structure. The basic class inheritance looks like:
* class BitFeature - Cool feature such as Wiki or Blog or Article, etc...
* --> class LibertyAttachable - Virtual Base class which adds handling of ((LibertyAttachments|attached files and resources)).
* ----> class LibertyContent - Virtual Base class upon which all "((LibertyPackage|content))" oriented classes derive (wiki, article, etc. )
* ------> class BitBase - a few utility functions common to every Bit class, and includes member variable mDb, a shared BitDb database object for all objects derived from BitBase.
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 BitFeatureGroup class might be designed, but this is uncertain for now.
A few rules of thumb:
# There should be _NO_ presentation code (no smarty assignments, no html generation, etc) in any class derived from BitBase. Two notable exceptions might be extreme error conditions or convenient $rs->GetMenu() calls
# 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 BitFeature derived class, see BitPage for real example
{code in="php"}
class BitFeature extends BitBase
{
// member var that hold corresponding data
var mRow;
function BitFeature( $iFeatureID = NULL ) {
// be sure to call base constructor!!!
BitBase::BitBase();
$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( $inParams as $key => $value ) {
$inParams[$key] = trim( $value );
}
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;
}
}
{code}