Jump to content

Designing a photo gallery with Plug-in feature question


OOP

Recommended Posts

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

Link to comment
Share on other sites

  • 3 weeks later...

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

 

 

 

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.