Plugin and theme architecture

ushahidi / platform

Ushahidi Platform API version 3+

http://ushahidi.com

Other

681 stars 506 forks source link

Plugin and theme architecture #34

Closed rjmackay closed 10 years ago

rjmackay commented 11 years ago

How to plugins / themes fit in?
How can they add to the API?
Can they modify the API?
How can they add to the UI?
What use cases should these cover?

rjmackay commented 11 years ago

A few thoughts around plugins and the API

we have to enable things like SMS and other data sources..
but these should still push data in through the API
Plugins should never modify existing API calls
Plugins may need add their own API calls (ie. for modifying that plugins data)

ekala commented 11 years ago

For cases where plugins add their own API calls, it boils down to packaging of the API. If the API is designed to run as an independent application, then there'd have to be two plugins:

One for the API - to add new the new API resources
One for the web client

rjmackay commented 11 years ago

Some ideas on how this could work

Plugins are modules (like 2.x)
Plugins can bootstrap themselves in using init.php
Plugins API accessible only by admin
Plugins should only add
- New API controllers
- JS to hook in to the frontend
- New models
We have a generic settings table for plugins to reuse
Provide various registries for adding to existing functionality
- Registry of attribute types
- Registry of input sources.

For an example.. SMSSync:

Would add an API controller to receive SMS (/posts/smssync ?)
- This might have to handle its own authentication
Would hook in to JS to add a settings page
Settings would be saved to existing settings api
Would create oauth client and tokens for each SMSSync device (?)

dkobia commented 11 years ago

Thought I'd leave some resources here since this has been bothering me as well:

Symfony inspired Event dispatcher - https://github.com/BRMatt/Kohana-Dispatcher
A Kohana 3.3 Event Module that we're all familiar with - https://github.com/thinkclay/Kohana-Event-Module

Additionally, one reason I had for wanting to move the API to its own module with Abstract classes was so that folks could rewrite and extend API functionality. This way plugins are not just 'Hooking' into the system but have the capacity to rewrite some functionality.

shadowhand commented 10 years ago

https://phabricator.ushahidi.com/T108