• Preface: The described plugin system below is currently implemented in dotproject.net, but it seems that it is dead. The described information could be useful for Feng Office, but it was not originally developed by me. I simply installed and used dotProject, and I have written some plugins using their system (as described below)

• TODO: What exactly are hooks, and what are the differences between hooks and plugins

• Plugins in my way of thinking:
  1. are pieces of code, images, etc, which extend the Feng Office functionality and introduce *new* things like a diary. A normal diary can be made as a document, but if I want to do some more things like searching inside or doing some statistics, etc, it is a good idea to encapsulate this information-centric functionality into a plugin.
  2. In my way of thinking, plugins normally should extend the horizontal menu in Feng Office (depending on the kind of plugin)
• Limitations of the current plugin system:
  1. One developer can overwrite code by accident with another developer because every plugin is zipped and is inside the Feng Office folder structure. When two different plugins are deflated, which had changes in the same file, the last plugin wins (lost-update-problem)
  2. Every (major?) update of the Feng Office distribution has a high potential of losing plugin functionality
• Must-Have-Features of a new plugin system:
  1. Installable, uninstallable, activatable, deactivatable, movable (in the menu, but depends on type)
  2. different kinds of plugin types like extend horizontal menu, extend context menu, etc
  3. can be configurable (ideally also via web in admin page)
  4. are able by themselves to create tables (when they are installed)
  5. are able by themselves to update tables (when a developer creates a new version)
  6. are able by themselves to delete tables (when they are uninstalled)
  7. provide information about themselves like name, current_version, description, dependencies on user plugins, etc
• Architectural thoughts:
  • Folder-structure
    1. All plugins should reside in a single subfolder of Feng Office, ideally called plugins
    2. Each plugin creates its own top folder (inside plugins), where all the stuff is that is needed by the plugin
    3. There should be a naming convention for creating the subfolder name
  • Database-Design
    1. Each plugin is allowed to create tables, which are needed due to the plugin's operation
    2. There should be a naming convention for tables, created by a plugin, prefix, etc
    3. Feng Office should be improved to use constraints (if it does not do so already) to limit plugin accidents
    4. Feng Office has to store some plugin-relevant information in its own table:
       • Name of plugin
       • Status of plugin (installed, installable)
       • State of plugin (activated, deactivated)
       • Version of the plugin
       • Storage location of the plugin (subfolder-name)
       • TODO
    5. This information must be checked against the folder when the plugin-administration-module is called to administer plugins
  • Class-Design
    1. There should be a setup.php at the top of the plugins folder to supply the methods and information needed during installation, administration, etc
    2. There should then be another entry point into the plugin, like an index.php or a class file, which is instantiated(info provided by setup)
    3. TODO
  • Procedural things and flow
    • Installation of a new plugin
      1. [ADMIN] deploys a new plugin into the feng-plugins-folder, called diary (the folder is then feng-base/plugins/com-example-diary-or-whatever)
      2. [ADMIN] browses to feng-plugin-administration-page (module)
      3. [Feng Office] reads information from the table to know about all plugins from the last folder scan and their status
      4. [Feng Office] reads all subfolders in the plugins folder and determines a new one, which does not match anything in the read table
      5. [Feng Office] Because it's new, it can only be installed. The setup.php information is read (array, or whatever), and some information is presented (description)
      6. [Feng Office] checks dependencies on other plugins (and versions) and, if everything is ok, shows the install button
      7. [ADMIN] clicks on install, after having read the description and developer remarks
      8. [Feng Office] executes install methods in setup-php, which should execute database statements, etc
    • Upgrade a plugin to a newer version
      1. TODO
    • Remove a plugin
      1. TODO
    • Configure a plugin
      1. TODO
  • Code-snippets
    1. setup.php: (an example I wrote for my old dotProject-installation 5 years ago)

<?php
// MODULE CONFIGURATION DEFINITION
$config = array();
$config['mod_name'] = 'Diary'; 
$config['mod_setup_class'] = 'CSetupDiary';
$config['mod_version'] = '0.8';
$config['mod_config'] = false;                        // show 'configure'
//some more config-details

class CSetupDiary {

function remove() {                                   // run this method on uninstall process
    db_exec( "DROP TABLE diary;" );                   // remove the diary table from database

    return null;
  }


  function upgrade( $old_version ) { 

    switch ( $old_version ){
    case "0.9":
      //do some alter table commands
      return true;

    case "1.0":
      //do some alter table commands
      return true;

    default:
      return false;
    }
  }

  function install() {
    // prepare the creation of a dbTable -> create diary
    $sql = "CREATE TABLE diary ( " .          
      "  diary_id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT" .
      ", diary_owner_id INT(11) UNSIGNED NOT NULL" .
      ", diary_header VARCHAR(100)" .
      ", diary_main TEXT" .
      ", diary_date DATE" .
      ", diary_last_modified TIMESTAMP" .
      ", PRIMARY KEY  (diary_id)" .
      ", UNIQUE KEY diary_id (diary_id)" .
      ") TYPE=MyISAM;";

    db_exec( $sql ); db_error();                 // execute the queryString through feng-api

    return null;
  }
}
?>

Feng Office STUDIO is a collection of tools to allow the user to customize fengOffice and build new applications within the fengOffice framework. We will look at 4 major aspects of custom alterations of Feng Office:

1. Re-think the administration front page (W.I.P.)
2. Modules Management
3. Field Management (W.I.P.)
4. Module layout (W.I.P.)

In doing so, we will focus on the GUI performance, which shall:

• Be intuitive by offering all available options at once
• Require the minimum possible amount of “clicks” to perform any given task

The first phase shall be a GUI re-design as a functional re-thinking. The administration front page shall present all that is available to the administrator at once. Possible designs include a common boxed layout that may appear very familiar to most administrators. In this layout, similar tasks are grouped together in window-like boxes. In this layout, each of the tasks is illustrated by the 3 elements: icon, name, and description.

• Description of the tasks (TBA)
• List of common tasks (TBA)

Fig:1 - administration front-page

controlpanelicons.tar

The second phase shall allow for managing modules. In this phase, the STUDIO takes form. The modules management page is accessed directly from the Administration front page, so EVERYTHING is at ONE click away. Module management allows users to start with a low level of customization, Modules are defined as one tab and all it contains; therefore a module has details, properties, and access. As such, those same parts should be presented to the user on a single page.

Fig. 2: The modules management page

There are 4 independent components on this page, each providing an additional level of customization:

1. Modules (listing)
2. Details
3. Properties
4. Permissions

The list is compiled on accessing the page, and the core modules are listed separately from the custom modules. This immediately tells the user that there are two classes of modules and to expect two different levels of customization. On first install, the Custom list is empty. The remaining components (Details, Properties, and Permissions) are blank until the user selects a module from the listing.

The Details component shows the details of the module, and the ONLY editable field is the order, allowing the user to rearrange the tabs.

• Changes are committed by clicking on the Save Changes button.
• The Delete and the Duplicate buttons are not active.
• The Properties component remains inactive: no changes allowed.
• The Permissions component is set to All by default, meaning that everyone having access to ANY of the workspaces can see this module.
• The administrator can change those permissions, thus controlling who can see which module.

All fields in the Details component are editable with the exception of the Owner field.

• Changes are committed by clicking on the Save Changes button, and the Delete and Duplicate buttons are active.
• The Properties component is active, and all fields are editable. Changes are committed by clicking on the Save Changes button.
• The Permissions component is set to All by default, meaning that everyone having access to ANY of the workspaces can see this module. The administrator can change those permissions, thus controlling who can see which module.

The details are retrieved from the module selected in the Module (listing). The behavior changes between the Core and Custom modules, but all the details are displayed at once. The data in the Details is the minimum requirement for creating a new component. Properties and Permissions can be left at the default values without affecting the functionality of Feng Office.

The Details component is active:

• The Order field displays the first available position.
• The text in the Name field will be the module’s name.
• The Owner field shows the current user name (Administrators only) and is NOT editable.
• The Description field is an optional field to hold the Module’s description and/or comments.
• The Tab Icon holds both the name and the image file for the graphic to be placed on the tab itself.
• The Tab label holds the text to display in the tab on the right of the icon.
• On Save, the image is saved on the server with the name set in the tab icon name.
• Properties and Permissions are set to default (See component description)

The data is committed, including Properties and Permissions, and a new module is created with the data shown on the screen:

• A new entry is added to the Custom Module (listing)
• A new tab will appear on the tabs bar icon and labeled as set on the Details (force refresh?)
• The focus remains on the newly created Module to allow changes to Properties and Permissions.
• On clicking the Duplicate button
• A new module is prepared with Details, Properties, and Permissions from the current module. The only exceptions are the Name and the Tab label that are prefixed with “CopyOf_”.
• All components are active.
• All data is presented to the user, but no change is committed until the Save Changes button is pressed.

The selected Module is deleted.

• The Module name is removed from the Modules (Listing).
• The corresponding Tab is removed from the tabs bar, and the position counter is reset to accommodate for the change.
• No Module in the listing has focus.
• The user must select a module from the list to proceed.

The Properties of a Module defines the TYPE of content and, for the Wrapper type, it also defines the actual content. The minimum set of types is:

1. Form (the default type) – This module is a collection of fields presented as a form that the user can fill in to gather data.
2. Data grid – This module is a listing of records of one or more fields used to present data to the user.
3. Wrapper – This is just a container to display another website.

• Only the Properties are saved; Details and Permissions are NOT saved.
• Focus remains on the current module.

The Permissions component gives the administrator the ability to select who can or cannot have access to (hide/display) each module based on the user's access to the workspaces.

• Only the Permissions are saved; Details and Properties are NOT saved.
• Focus remains on the current module.

The third phase shall allow managing Fields. Here is where the STUDIO really takes form. The Fields management page is accessed directly from the Administration front page, so EVERYTHING is at ONE click away.

Fields have details, types, and properties. As such, those same parts should be presented to the user on a single page.

A recommended minimum set of field types should be:

• Single line of text
• Multiple lines of text
• Choice (menu/list to choose from)
• Number (1, 1.0, 100)
• Currency ($, ¥, €)
• Date and Time
• Lookup (information already on another table)
• Person (link to person in the contacts/user list)
• Hyperlink
• Picture
• Calculated (calculation based on other fields)
• Cascading Lookup

Properties are dynamically loaded based on the field type (contextual??)

W.I.P.

The fourth phase shall allow managing modules layouts. The Layout management page is accessed directly from the Administration front page, so EVERYTHING is at ONE click away.

Layouts have details and views. As such, those same parts should be presented to the user on a single page.

A recommended minimum set of views layout should be:

• Data entry (Presented to the user for entering data)
• Data view (presented to the user when consulting existing records)

W.I.P.