History of bitweaverPackage

{maketoc}
The central architectural concept in bitweaver is known as a "Package". This is just a directory with all the files relating to a particular feature. We call it a Package because it is larger than a plugin. In fact, and package can have it's own plugins, such as the LibertyPackage. The term *modules* was already taken for the display blocks that appear on the borders of the page.

!Package Architecture
^The design is simple: Put all files related to each feature into their own directory^
__A bitweaver package is simply a directory in the bitweaver root directory.__ An optional requirement is a be bitweaver-centric initialization file called "bit_setup_inc.php" that will get included by the KernelPackage during initialization. A bitweaver package can be a set of highly integrated features such as the WikiPackage or BlogPackage or it could be an external app, like phpBB, adopted to use the bitweaver framework with minimal modifications to keep it VirginSource.

The KernelPackage will automatically create __two standard 'define's__ for every package: <NAME>_PKG_PATH and <NAME>_PKG_URL, where <NAME> is simply your package name (aka, the name of the directory in the bitweaver root.) For example, FISHEYE_PKG_PATH and FISHEYE_PKG_URL will be created for the FisheyePackage. You can easily rename the package directory and you don't have to touch a line of code or setting anywhere. Yes, just move "fisheye" to "[/photos|photos]" or "phpbb" to "[/forums|forums]" and reload your browser.

The solution is low tech and dirt simple. bitweaver does not __insist__ on a large API infrastructure when some TikiPackages might only need to execute a few lines of code. Other bitweaver packages might need to access a more complex bitweaverAPI. So let developer's decide for themselves how simple or complex to make their own Package. This should also allow ports to stay as virgin as possible, and stay much more up to date with their own code base.

Using packages, features can be added and removed at will, without breaking things. By segregating and creating Packages for all the existing TikiWiki features, we not only remain on par with TikiWiki as a feature set, but open the doors to many more application integrations and feature rich opportunities. It also gives the Packages flexibility and robustness to grow at their own rate.


Be sure to read ((TemplatesPackage)).

Here is an example of the directory structure:
{code in="bash"}
root/
+ articles/
+ blogs/
+ admin/
- admin_blogs_inc.php
- schema_inc.php
- upgrade_inc.php
+ templates/
- admin_blogs.tpl
+ modules/
- mod_last_blog_posts.tpl
- mod_last_blog_posts.php
- bit_setup_inc.php
- blog_lib.php
- blog_rss.php
- edit.php
- index.php
- list_posts.php
- post.php
- print_post.php
- rankings.php
- send_blog_post.php
- view.php
- view_post_image.php
- view_post.php
.
+ phpbb
- bit_setup_inc.php
+ templates/
- menu_phpbb.tpl
.
+ wiki
.
{code}

The kernel will define two global constants for every pacakge. See KernelInitialization for more info...

!Life Cycle of a Package
!!Install
* package version check (table in the database) to indicate previous install and upgrade requirements
-=New Install=-
* package tables are created if they don't exist and default values populated
* package settings are inserted into bit_preferences
-=Upgrade Install=-
* upgradeBitweaver will handle upgrading the files
!!Initialization
* __bit_setup_inc.php__ is read from package dir
* application menu is registered
* miscellaneous initialisation code is executed
Page History
Date/CommentUserIPVersion
02 May 2007 (12:54 UTC)
gravyface74.110.109.8314
Current • Source
spiderr69.134.144.313
View • Compare • Difference • Source
Chaim Krause69.23.127.7112
View • Compare • Difference • Source
spiderr66.93.240.20411
View • Compare • Difference • Source
spiderr66.93.240.2048
View • Compare • Difference • Source
Stephan Borg218.214.1.1137
View • Compare • Difference • Source