|Version 14 (modified by 9 years ago) ( diff ),|
Table of Contents
A plugin is any modification to a system that can be applied independent of the base installation. Supporting plugins would allow people to extend Sahana Eden without their code needing to be added to trunk, and keeping their eden repository clean. This helps prevent merge conflicts between a customized site and trunk, and reduces the pressure to fork. It is possible that some non-core features supported by the Sahana Software Foundation could be delivered as plugins.
WordPress has plugins -- north of 25,000 of them. They're one reason for its great popularity, as it permits [a very large number] of independent developers to offer features. Ushahidi has plugins -- just recently, the lead for NepalMonitor offered two plugins written by the Nepalese developer group Himalayan Techies. Web2py has plugins...and Web2py applications are plugins too. These are examples of products that get benefit from plugins, plus a bit of push to Keep Up with the Joneses.
Plugins also provide an outlet for frustrated wannabe Eden devs who can't get their features accepted into trunk, and those who want to use Eden for a somewhat non-target use. (They'll let me add a kanban module, so I have someplace to point a kanban phone app. --Pat)
Not all of these are equally likely to be requested and used, or deemed necessary. The items are ranked +++ highest likely need, down to + not particularly urgent, shown following the proposed use case.
A site wants to add fields to an existing primary resource, and have them show up in the primary resource's Basic Details form. These will be 1-1 with the primary resource records. +++
A site needs to add a new 1-N component to go with an existing primary resource. +++
A site needs an entire new module with model / controller / view, that yet makes use of existing tables, including having them as components. +++
A site wants to match the look and feel of other tools they use, including types of widgets. E.g. they may want to replace the map viewer with one that they use in another application. + because this is handled by templates and that functionality is working. However, if we can make templates into plugins, we would not need to store everyone's templates in trunk. In that case, +++
Note: It is very easy already to have a template kept out of the main repo via a .gitignore so this seems lower priority to Fran
- The admin wants to be able to browse a repository of plugins, viewing their names, descriptions, social rating, who maintains them. ++
- Installation should be no harder than installing a Web2py application, plus some configuration editing. ++
- Ideally they would to be able to click on a hyperlink to easily install them into their running instance of Eden. +
The Developer wishes to be able to develop new functionality which extends a base Eden install without needing to have anything added to trunk. +++
They may want this for any of several reasons:
Their feature involves something confidential to the site. ++
(Following to be updated.)
This functionality may include:
- Controller Customizations
- Applying the Widgets to existing modules would be done in controller customizations in templates
- A plugin is a Web2Py application which acts as a co-app to the main Eden instance.
- The plugin will have standard files to identify itself to Eden:
- Metadata (Name, Description, Maintainer)
- Menu entries
- List of Modules to be added to Auth UI
- The Eden instance can be configured with a list of plugins using
settings.plugins = ["plugin1", "plugin2"]
- This could be done in either models/000_config.py or a Template (unless this plugin includes the Template!)
- Q: How can we download these from a URL if not found?
- S3Menu to be extended to read the settings & add additional menu entries found in those folders
- Templates which don't use S3Menu will not support these, but that's seen as a bug in these templates
Once implemented the design will move here: