How to use it

Download the w2p file here, install it on web2py, and run the application pluginClassTestpie. Prerequisites are the same as those for the 'cairo piechart' (slice12), i.e., Python, Python modules for cairo vector graphics library (python-cairo in Debian) and web2py.

What it does

The application does the same as the slice12 'cairo piechart' except that it's restructured to be close to a class-based plugin.

What is class-based plugin for web2py

One of the experimental plugin schemes discussed in the web2py community.

Plugins are stored in plugins directories: under the directory for web2py,

web2py
  |_ plugins
  |_ applications
      |_ plugins
      |_ myapp
          |_ plugins

The plugins directory under web2py is for storing system plugins. The plugins directory under the applications directory is for storing plugins shared by applications. The plugins directory under each application (e.g., myApp) is for storing plugins specific to the application.

In each plugins directory, there are files, e.g.,

__init__.py
plugins.py
sample_plugin.py

where __init__.py is an empty file to make the directory work as a package, plugins.py contains an abstract (nominal) class for plugins, and samplePlugin.py contains a class named SamplePlugin and codes for the plugin.

In plugins.py, an abstract (nominal) class is defined as

class PluginA(object):
    def model(self): pass
    def controller(self): pass
    def view(self): pass

A plugin class SamplePlugin in sample_plugin.py inherits it as

class SamplePlugin(PluginA):
    aData = []
    ...
    def model(self,...):
        ...
    def controller(self,...):
        ...
    def view(self,...):
        ...

What is good about class-based plugin scheme

• hierarchical and extensible development of plugins
• simple and plain interface with web2py
• a plugin-wide namespace with hiearchy
• no need to change web2py itself
• no side-effects
• easily portable
• (more to list)

What is bad about class-based plugin scheme

• need to understand proper use of classes
• need to handle class hierarchy properly
• (more to list)

A case study with cairo piechart

1. A plugins directory is created under applications/test_pie.

   applications
    |_ test_pie
          |_ plugins
               |_ __init__.py
               |_ plugins.py
               |_ pie_chart.py
   

2. In pie_chart.py, class PieChart is defined. It has data variables (data, style_data) and a medhod 'controller'.

3. Classes PPart and IMPie in the module im_pie.py in 'cairo piechart' application are copied into pie_chart.py.
4. The controlling part of the 'pie' function in the original module im_pie.py is moved to the 'controller' method in pie_chart.py.
5. In test_pie/models/db.py, the PieChart class is instantiated and data for the chart is assigned to the class' data attributes. The instance is named pieChart.
6. In the index function of test_pie/controllers/default.py, pieChart.controller() returns an IMPie instance pie. The function draw_pie returns the chart image data in PNG format.
7. The URL of the chart image pie_src is handed to view/index.html.
8. In view/index.html, the chart image is added by an img tag with the source pie_src handed from the controller.

To do

1. Apply the class-base scheme to other examples, and develop/improve the scheme.
2. By applying to examples, find merits/demerits, advantages/disadvantages, and possibilities/limitations.
3. Find a good way to organize/manage the plugin system.
4. Figure out the relation to components/libraries such as gluon.

Note

• Changed naming conventions a bit. (2009.10.31)