Including files
Includes should use an API function to ensure the base directory is correctly dealt with (this has many advantages over constants). Need to think how this works before API is instantiated of course.Something like:
$include_ok = $tp_api->_include('pkg/gallery/subdir/file.php');
$include_ok = $tp_api->_include('kernel/template/template.php');
class tp_api {
function _include($path) {
$path = $tp_api->get('config[tp_path]') . "$path";
if ( file_exists($path) ) {
include $path;
return true;
} else {
return false;
}
} // end function include
} // end class tp_api
This relies on the directory structure within bitweaver, but it avoids the database mod to Tiki 1.8 and a hell of a lot of overhead.
What to call the core?
Core is no good as it has unpleasant unix connotations (core dump). Kernel has been mooted, but it is too easy to misspell as kernal.Directory structure
| /index.php | All functionality is called through this file (except install, possibly rss/wap) which is designed to live in the web root. Shouldn't really do much except save start time, set entry condition constant and call /tp/bitweaver.php, dealing with an error if the file system is broken. |
| /tp/ | All bitweaver code lives under this directory, leaving the web root uncluttered for other directories - we might want to run other applications! |
| /tp/bitweaver.php | This file should do it all - include the kernel, instantiate tp_api and process the request, including the approriate file. |
| /tp/api/ | Contains api_bitweaver.php, which contains tp_api, the API class for bitweaver! Contained in a single file for easy maintenance, but the methods in this class should only contain wrappers to methods in the kernel. See OneOfManyAPI. May also contain alternative APIs eg for customised interface to external user groups. |
| /tp/kernel/ | Contains the kernel ie stuff which is vital to the operation of nearly every instance of bitweaver. Also contains (for ease of maintenance) the package-like code for maintining kernel elements - users, groups etc. |
| /tp/kernel/config.php | Good old config. |
| /tp/kernel/config_db.php | Database connection config - would be nice to encrypt this. |
| /tp/kernel/user/ | |
| /tp/kernel/group/ | |
| /tp/kernel/categ/ | Many users need permissions by category with inheritance; bitweaver therefore needs a new implementation of categories and permissions to fit. |
| /tp/kernel/auth/ | Authentication of a request belongs here, including anti-session hijacking, CSRF code etc. Possibly combine this into a single 'tp_http' class. |
| /tp/kernel/perm/ | |
| /tp/kernel/session/ | Possibly combine this into a single 'tp_http' class. |
| /tp/kernel/cookie/ | Possibly combine this into a single 'tp_http' class. |
| /tp/kernel/mail_out/ | (needed? probably just a wrapper call to sendmail in bitweaver.api) |
| /tp/kernel/mail_in/ | (needed? probably just use pear pop3 class) |
| /tp/kernel/search/ | need a class for registering search hooks; should integrate with permissions (ouch) |
| /tp/kernel/package/ | class for managing packages |
| /tp/kernel/theme/ | class for managing themes |
| /tp/kernel/settings/ | class for managing settings |
| /tp/kernel/template/ | templating class - wrapper for smarty |
| /tp/kernel/smarty/ | |
| /tp/kernel/adodb/ | |
| /tp/kernel/.../ | |
| /tp/pkg/ | Contains packages ie stuff which provides functionality but is not vital to the operation of everything else (should wiki parsing be in the kernel?). Some packages may be used by others (eg comments) but that is a different matter. |
| /tp/pkg/wiki/ | |
| /tp/pkg/comments/ | |
| /tp/pkg/gallery/ | |
| /tp/pkg/menu/ | |
| /tp/pkg/..../ | |
| /tp/pkg_data/ | Default location for package data eg. image gallery files. This should not be for uploaded data, which should be in different user-configurable directory (/tp/upload/ by default). Packages should store their data in a subdirectory of this named after their own name. |
| /tp/pkg_data/gallery/ | image files |
| /tp/theme/ | For themes ie .tpl, .css and .img files (and scripts which are theme specific). Note that all presentation images are by definition part of a theme and should be included here. Packages' own presentation images cause a dilemma - is it viable to have these in the package but allow overloading in the theme? |
| /tp/theme/default/ | Default theme |
| /tp/theme/default/scr | |
| /tp/script/ | For javascript which may be used by many themes (package-specific JS should be in a subdirectory of the package; this is for theme-related javascript eg. phplayersmenu) |
| /tp/debug/ | |
| /tp/doc/ | |
| /tp/install/ | |
| /tp/temp/ | Cache and other temporary files |
Some general rules:
Collision avoidance:
All global variables must have names prefixed with $tp_All classes must have names prefixed with tp_
All functions declared outside a class (preferably don't do it anyway) must have names beginning with tp_
All constants must have names beginning with _TP_, but for preference use a property of the global class $tp_api rather than a constant.
kernel classes are named like tp_kernel_users and instantiated as $tp_kernel_users; they must not be accessed directly, only through the API ie global $tp_api.