As written in Envisage documentation, the applications we write need to change over time. We fix bugs, and we add, modify, and remove features. In other words, we spend most of our time either fixing or extending applications.
Sometimes we extend our applications by changing the actual code, sometimes we have other ad hoc extension mechanisms in place – a text file here, a directory of scripts there. As applications grow, they often end up with numerous places where they can be extended, but with a different extension mechanism at each one. This makes it hard for developers who want to extend the application to know :
- where they can add extensions
- how to add them
Warning
For concrete documentation on how to extend OpenAleaLab, see Plugins
- Trac component architecture
- Yapsy (yet another plugin system) (example of plugin framework. Several links inside)
- Envisage
- PyUtilib, Architecture Doc (PDF)
- Another simple framework
Variable or variables describing plugin. work in progress: Potential useful information:
- classical meta info (name, icon, desc, authors, license, ...)
- python/qt compatibility (does-it work with PyQt4 ? PySide ? Qt 5)
- python compatibility (python 2 ? python 3 ?)
- interfaces implemented by this widget
- dependencies required
These information are used to filter search results. For example:
# Return all widgets
results = search('oalab.applet')
# Example of filter in basic query language
# Return all widget written by John Doe
results = search('oalab.applet', author='John Doe')
Depending of data description structure, we can imagine advanced query languages like SQL, SPARQL, or based on existing libraries
Possible approaches for plugin description:
name = 'HelpWidget'
authors = ['John Doe']
data = {
'name' :
'oalab': {
'extensions': ['plantlab', 'tissuelab'],
},
}
data = """
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix oa: <http://openalealab.org>
oa:helpwidget
dc:title "HelpWidget";
dc:publisher "OpenAleaLab"
.
"""