History of bitweaverPackage

Differences from version 7 to 14



@@ -1,26 +1,33 @@

 {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 Tiki Package is simply a directory in the Tiki root directory.__ An optional requirement is a folder inside your package directory called "tiki". Inside it will be tiki-centric initialization files such as a file called "tiki_setup_inc.php" that will get included by the KernelPackage during initialization. Other optional files will include a "local_inc{{.$tikidomain}.php" for settings particular to a user's install. 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.
+__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 Tiki root.) For example, IMAGEGALS_PKG_PATH and IMAGEGALS_PKG_URL will be created for the "imagegals" package.
+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. TikiPro 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 TikiProAPI. 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.
+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:
-
+{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

@@ -35,27 +42,25 @@

  - view_post.php
  .
  + phpbb
- + tiki/
- - tiki_setup_inc.php
- - tiki.tpl
+ - bit_setup_inc.php
+ + templates/
+ - menu_phpbb.tpl
  .
  + wiki
  .
+{code}
+
+The kernel will define two global constants for every package. See KernelInitialization for more info...
 
-The kernel will define two global constants for every pacakge. See KernelInitialization for more info...
-!Packages To Do
-# Abstract DB initialisation and remove ''db/tiki-x.y-zzzz.sql'' files down to one. Use SQL92 as the defacto standard and re-write DB convert query functions to support __create table__ and __drop table__ functions. This is to allow Package developers to write all their database modifications using SQL92 syntax which is then converted accordingly into the correct DB driver format. This is currently done for most SQL commands and should be a relatively simple modification.
-# Create a package installation/configuration code for TikiPro - would like to suggest a look at [http://www.dotproject.net/|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.
-# Begin breaking features into installable packages that can be added and removed at will, without breaking things. By segregating and creating Packages for all existing TikiWIki features, we not only remain on par with TikiWiki as a feature set, but open the doors to many more application integration and feature rich opportunities. I believe with the work already carried out by Spider, the segregation part is mostly done and as the Packages code is a pre-requisite, this should be a time-consuming but fairly simple task. It will also give us an opportunity to test out our Packages code for flexibility and robustness.
 !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
+* package settings are inserted into bit_preferences
 -=Upgrade Install=-
-* upgrade script from old to new version run if already installed (see [http://www.mantisbt.org|Mantis] db upgrade scripts)
-!!Initialisation
-* __tiki_setup_inc.php__ is read from package dir
+* 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