History of bitweaverPackage

Comparing versions
Version 8Current version

Package Architecture

The design is simple: Put all files related to each feature into their own directory

A Tiki Package is simply a directory in the Tiki root directory. An optional requirement is a be tiki-centric initialization file called "tiki_setup_inc.php" that will get included by the KernelPackage during initialization. A TikiPackage 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 Tiki 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 Tiki root.) For example, IMAGEGALS_PKG_PATH and IMAGEGALS_PKG_URL will be created for the "imagegals" package.

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 TikiPackages 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.

These packages mean feature 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:

root/
+ articles/+ blogs/+ admin/- admin_blogs_inc.php
+ templates/- admin_blogs.tpl
+ modules/- mod_last_blog_posts.tpl
- mod_last_blog_posts.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+ tiki/- tiki_setup_inc.php
- tiki.tpl
.
+ wiki.

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

Packages To Do

  1. Create a package installation/configuration code for bitweaver - would like to suggest a look at dotProject package configuration be used as a possible model for this. The interface is highly recommended as easy to use and intuitive. Not sure how this will work and/or how it will be implemented.

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
  • features are inserted into tiki_preferences
Upgrade Install
  • upgrade script from old to new version run if already installed (see Mantis db upgrade scripts)

Initialisation

  • tiki_setup_inc.php is read from package dir
  • application menu is registered
  • miscellaneous initialisation code is executed</name></name></name>
 
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>
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