× Table of Contents Plugins API Ideas Contributors Plugins API Ideas Let me elaborate on how i feel a plugin should work. ill start by saying that i am by no means an experienced developer so my view of this may be completely off from proper architecture for this sort of thing. this is kind of just a brain dump of what im thinking after mucking with the internals of feng for a few hours. anyways, unless there is a different way, to add a module with a tab at the top and a view, you have to actually modify some files of the installation, ie. og.js i believe, to add the tab. i think a proper plugin system should not require any kind of file modification. now i realize that a plugin would at the very least require more than one file, for images for example, and at the very most, require a bunch of files to be added such as the current case. using more than one file would serve to clean up the code a bit instead of stuffing everything needed in one file. i think there should be a plugins directory under the root dir of the installation. any plugin or module would be added to the plugins dir. the framework should provide at the least a clean and object oriented way to program an add on module with view and tab. i realize that some addons would have to be a bit more involved and may be more of a hack depending on what part of the suite they modify. i think it is nice how the controller class is extended, but i think that modularity needs to be applied to adding a tab as well, instead of having to modify the og.js file or whatever. it is also nice how the controller and the view are separated and this is good practice. formatting and markup should always be separate from code. i guess ideally the framework should provide an extensible way to install & initialize, display, and uninstall. also it should provide classes and methods for database access and for pulling information from any aspect of the suite in an oo-way. maybe this is all here already and im just not seeing it - documentation is really needed so every developer doesnt have to re-learn how the entire system works to extend it. im not really qualified to do this - someone who has been working with this code and knows it inside and out really, really needs to write some documentation. code comments are pretty sparse as well which doesnt help. so here is a very basic idea of what im thinking about: the plugin has a set kind of file/folder structure like with the current plugins. the plugin dir is dropped into the plugins folder of the installation. user goes to the admin panel, plugins, then the frameworks scans the plugins dir for new folders, if the new one is found, it gives the option to install, or if it is installed, uninstall it. Controller File: class NewController extends ApplicationController { function install() //this is called by the framework when the plugin is first installed. it is recommended to setup the db tables in this function if the module uses the db. the framework provides classes and methods for accessing the db. also a function can be called to set up a tab for the plugin. or maybe the tab can just be setup in a separate file, but not modifying js files in the installation as it is currently done. function uninstall() //this is called when the plugin is uninstalled. it is recommended to delete the tables in the db that were created during installation function init() //this is called when the tab for the module is clicked. here the module will display its main page. output is sent to the template engine and to the view file just as it is now } then of course there is the view file, associated style sheets and images, etc. but main idea is that there would be a clearly defined structure for setting up a plugin, and the plugin would have access to clearly defined and well documented classes and methods for interacting with the suite, like changing views/tabs, reloading the view, popping up dialog boxes, reading contact info, calendar info, etc, also accessing its own tables in the db. i dont know if all this exists already, maybe it just needs to be documented well. Source by bmw5002 Contributors bmw5002 Log In