OOP Posted August 16, 2009 Share Posted August 16, 2009 Hi there, I have been working on my own photo gallery application for almost 1 month and everything is working fine. I need to have the plugin feature in my application so that i can add extra functionalities whenever needed very easily without hacking the core code. However, i can not seem to understand this concept. What is the best way to have this done? How should I go about it? I need some ideas, comments, code examples if possible Any help is highly appreciated Quote Link to comment Share on other sites More sharing options...
mystery_man Posted September 3, 2009 Share Posted September 3, 2009 This is something I have been pondering on myself. I have found it difficult to imagine how to build an interface for adding modules/plugins on the fly, as I also want to use such functionality for a project I am working on. Here are some usefull questions and my opinions on them: 1. What should the modules be able to do? Most probably, this will encompass Create-Read-update-delete (CRUD, and I use these terms very generically) functions, I think most other operations can be performed provided that these 4 features are presented and available. Eg, if some reporting needs to be done on existing data, the READ function should be all that is needed. The other 3 'umbrella' functions will obviously be more complex to work with. 2. How can the modules interface with the core of the application? This can be achieved by using some kind of API to provide the CRUD generically to modules that will make use of these functions. This is how, for example, facebook enables developers to build their own facebook apps. The API is developed, documented and provided to developers by facebook to use in their applications they build for facebook. From an OOP perspective (for an application much simpler then facebook!), I would think that the API would take the shape of a class/model that provides abstraction between the functionality of the CRUD and how they are implemented (the business logic and all the code behind them). Example: a) You have a DB table for your photos. b) You have a class, 'PhotoObject' which models a photo, and: - contains attributes like id, name, description, filename, size, author - contains CRUD functions and other operations that is related to working with the photos. c) You have an API implementation in the form of a class, 'myAPI', that: - uses functionality of the PhotoObject and other Classes used in the application - provides the CRUD functionality that is generic enough to be reused by modules that are still to be written (but we know they will need CRUD functions, thus we have an idea of what the API class should look like). After writing a module, the API will probably be altered. 3. How can the core be desinged to simplify the interfacing with modules? I assume the main goals in achieving the right kind of environment for a 'plugin system' is to build the framework of the app in such a way that it is very modular, and that the different VMC layers is effectively separated from each other. I also assume that this 'API' will be similar to controllers - and come to think of it, a Controller in the VMC model acts sort of like an API anyway - but it will be more generic in design and more 'transparent' in terms of usage. These are my thoughts, although I am by no means an expert on application design - yet. I hope this at least gives some ideas of what to look for. Regards Quote Link to comment Share on other sites More sharing options...
ignace Posted September 4, 2009 Share Posted September 4, 2009 Plugins are based upon the observer pattern, when a plugin is loaded it registers itself to 'hook' into a section of your application: $pluginRegistry->register(new Plugin('sectionHook')); Afterwards when you reach a section of your application that allows plugins: $someClass->getPluginsFor('sectionHook')->execute($dataObject); Every plugin now gets the $dataObject passed and has the ability to modify it, for example user entered text: the 1st plugin modifies all e-mail addresses into clickable 'mailto:' addresses, the 2nd plugin modifies all web addresses to clickable web addresses, .. A module is part of a modular application (or a module is a mini-application inside of your application, some use the term widget instead of module) A module contains everything it uses (images, scripts, styles, libraries, ..) unless it's already present in the main application. Using this approach makes it possible to drag-and-drop your module into another application (atleast if it contains the libraries your module requires). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.