Translations of this page?:

Thoughts about a new plugin-system

  • Preface: The described plugin-system below is currently implemented in dotproject.net, but it seems that it is dead. The described information could be usefull for Feng Office, but was not originally developed by me. I simply installed and used dotProject and I have written some plugins using theire 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 possibly want do some more things like searching inside or do some statistics etc, it is a good idea to capsule this information-centric-functionality into a plugin.
    2. In my way of thinking plugins normally should extend the horizontal menu in Feng Office (depends of the kind of plugin)
  • Limitations of current plugin-system:
    1. One developer can overwrite code by accident of another developer, because every plugin is zipped and has 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 loosing plugin-functionality
  • Must-Have-Features of a new plugin-system:
    1. installable, uninstallable, activatable, deactivateble, movable (in menu, but depends on type)
    2. different kinds of plugin-types like extends horizontal menu, extends 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 to 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, which 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-operation
      2. There should be a naming convention for tables, created by a plugin, prefix, etc
      3. Feng Office should be improoved to use constraints (if it does not do already) to limit plugin-accidents
      4. Feng Office has to store some plugin-relevant information in an own table:
        • Name of plugin
        • Status of plugin (installed, installable)
        • State of plugin (activaed, deactivated)
        • Version of plugin
        • Storage-location of plugin (subfolder-name)
        • TODO
      5. This information must be checked againt the folder, when the plugin-administration-module is called to administer plugins
    • Class-Design
      1. There should be a setup.php in 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 (folder is then feng-base/plugins/com-example-diary-or-whatever)
        2. [ADMIN] browses then to feng-plugin-administration-page (module)
        3. [Feng Office] reads information from table to know about all plugins from last folder-scan and their status
        4. [Feng Office] reads then all subfolders in plugins-folder and determines a new one, which does not match against anything in the read table
        5. [Feng Office] because its new, it can only be installed. setup.php-information is read (array, or whatever) and some information presented (description)
        6. [Feng Office] checks dependecies to other plugins (and versions) and is everything is ok, shows 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;
  }
}
?>

functional specifications for the development of fengOffice STUDIO

introduction and summary

fengOffice 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 FengOffice:

  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 amounts of “clicks” to perform any given tasks

administration front page

The first phase shall be a GUI re-designs 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.

Please note that I have intentionally omitted:
  • Description of the tasks (TBA)
  • List of common tasks (TBA)

Fig:1 - administration front-page


In case someone wants the icons:

Module management

The second phase shall allow 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. Modules management allows user to start 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 in one single page.

Fig. 2: the modules management page

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

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

Modules (listing)

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.

On selecting one of the Core modules:

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 on 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.
On selecting one of the Custom modules:

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

  • Changes are committed on clicking on the Save Changes button and the Delete and the Duplicate buttons are active.
  • The Properties component is active and all fields are editable. Changes are committed on 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.

Details

The details are retrieved from the module selected in the Module (listing). The behavior changes between 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 fengOffice.

On clicking the New Module button

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 the 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 components description)
On clicking the Save Changes button

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

  • A new entry is added to the Custom Module (listing)
  • A new tab will appear on the tabs bar icon and label 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. 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.
On clicking the Delete button

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.

Properties

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.
On clicking the Save Changes button
  • Only the Properties are saved, Details and Permissions are NOT saved.
  • Focus remains on current module.

Permissions

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

On clicking the Save Changes button
  • Only the Permissions are saved, Details and Properties are NOT saved.
  • Focus remains on current module.

Field management

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 in one 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 (contestual ??)


W.I.P.

Module layout

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 in one single page.

A recommended minimum set of views layout should be:

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

W.I.P.

Discussion

PLEASE NOTE: Comments to the wiki should only contain suggestions and questions that help us to improve the manual (and not the software). These comments will be deleted as soon as the information has been integrated into the manual.

Posts that do not contribute to the DOCUMENTATION of the project will be DELETED.

Ask QUESTIONS on the product here.
Report BUGS here.
Propose NEW FEATURES here.


Ignacio de Soto, 2009-12-16 20:02

Great work so far!

I'm not sure how would it work to have all of the plugin in some subfolder in OpenGoo. For example, if my plugin adds a new controller to OpenGoo, should OpenGoo load the controller from my plugin folder? What if two plugins have a controller with the same name? Or should each plugin will have it's own MVC independent from OpenGoo's? I think allowing to extract files anywhere in OpenGoo will simplify many things, but we do need some naming convention to avoid collisions.

I like everything you wrote about how to set up a plugin.

We need to get more developers' suggestions.

Don Robertson, 2010-01-13 04:29

Hi - putting plugins into their own folders makes life a lot easier. I use Drupal a lot, and Drupal has a modules folder with the core modules in it and another folder for site specific modules.

This makes it a lot easier to remove and update modules, keep track of any modifications, remove redundant files etc.

In Drupal speak, a hook:

“Allow modules to interact with the Drupal core.

Drupal's module system is based on the concept of “hooks”. A hook is a PHP function that is named foo_bar(), where “foo” is the name of the module (whose filename is thus foo.module) and “bar” is the name of the hook. Each hook has a defined set of parameters and a specified result type.

To extend Drupal, a module need simply implement a hook. When Drupal wishes to allow intervention from modules, it determines which modules implement a hook and calls that hook in all enabled modules that implement it.

The available hooks to implement are explained here in the Hooks section of the developer documentation. The string “hook” is used as a placeholder for the module name in the hook definitions. For example, if the module file is called example.module, then hook_help() as implemented by that module would be defined as example_help().”

I mostly use the hooks in the themeing system - for example,

function <theme-name>_breadcrumb($breadcrumb) {

     !-- custom breadcrumb code -->

}

The other thing I really like about Drupal's module system is how it keeps track of the module versions. Drupal can check the Drupal website and let you know if new versions of your installed modules are available. I use other web based applications where it is almost impossible to know if a module is updated or not - each new version is uploaded as a new file. Just finding what version you are using is a pain.

Feng Goo (pun - feng shue? never mind) won't have this problem at the moment - but I guess we all hope it will be a problem before long :-)

lexa, 2011-03-16 07:45

Hello

The two teams of Silex and amfPHP are mutualizing their efforts to develop a simple yet powerful plugins system for web applications. This is an initiative of Silex Labs, non profit organization ( see projects.silexlabs.org )

Below is a description of the project.

A prototype is already running in Silex. It allows this ria / web application, to list the available plugins form the exchange platform ( see exchange.silexlabs.org ) and to install it in one click. The application is then able to display notifications when the installed plugins have new versions, and to update them on demand.

In the other hand, the plugin creators can package and deploy their plugins with the help of the exchange platform. The versioning and the dependencies between plugins is handled automatically.

Thechnically, the exchange platform is a wordpress plugin, which turns a wordpress blog into a platform which can communicate with the php classes developed to handle plugin installation / update.

For the plugins itself, a small API has been set up in order to allow very easy interaction with a framework, such as Silex core, or amfPHP core. Hooks and filters are used to modify/enhance default system behavior. And these classes also offer a multilingual localization mechanism.

After this prototype has proven its efficiency, we will need to make it industrial, add/remove functionalities and make it more generic for use in other web applications. If one of the Feng Office developer wants to participate in the next iteration, to be part of the discussions about the specifications or even to help developing the missing parts, let us know by email a.hoyau at silexlabs.org

Bye, lexa.

Description

Because the web applications start to have sufficient maturity and robust structures. They start to become “big” projects with a lot of code and coders. More and more projects need to keep a clean and simple core code base, putting a lot of the secondary functionnalities into plugins. It makes it easyer to maintain and deploy an application, and it lets more developpers take part to the developpment, either they have new ideas, different needs, or less skills than the core team.

Be focused on the core code and team

Projects which could be interested

  • feng office
  • amfphp
  • silex
  • piwik
  • web2project

Anyone has more ideas?

Useful links

functionalities

plugins architecture

  • instanciation
  • hooks and filters
  • activation
  • configuration
  • localisation system (optional)
  • XML description file (generator, comparison, …)
  • unit tests?

plugins distribution

  • exchange platform
  • dependences between elements
  • installation / uninstall
  • update and versioning
Enter your comment
 
thoughts_about_a_new_plugin-system.txt · Last modified: 2013-02-27 18:06 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported


Terms of Service | Copyright © 2014 fengoffice.com