bitweaverPackage

The central architectural concept in bitweaver

Created by: spiderr, Last modification: 02 May 2007 (12:54 UTC) by gravyface
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 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" or "phpbb" to "forums" and reload your browser.

The solution is low tech and dirt simple. bitweaver does not insist on a large API infrastructure when some packages might only need to execute a few lines of code. Other packages might need to access a more complex bitweaverAPI. So bitweaver lets developers 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 features, the doors are opened to many application integrations. It also gives new packages the flexibility and robustness to grow at their own rate.

Be sure to read TemplatesPackage.

Here is an example of the directory structure:

 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
 .


The kernel will define two global constants for every package. 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</name></name></name>