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:
|
+All bitweaver classes follow the same structure. 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
|
+* 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 TikiFeatureGroup class might be designed, but this is uncertain for now.
|
+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 TikiBase. Two notable exceptions might be extreme error conditions or convenient $rs->GetMenu() calls
|
+# 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 TikiFeature derived class, see TikiPage for real example
|
-
|
- class TikiFeature extends TikiBase
|
+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 TikiFeature( $iFeatureID = NULL ) {
|
+ function BitFeature( $iFeatureID = NULL ) { |
// be sure to call base constructor!!!
|
- TikiBase::TikiBase();
|
+ BitBase::BitBase(); |
$this->mFeatureID = $iFeatureID;
|
}
|
|