Synopsis:

Porting phpMyAdmin a clean OOP structure, in order to ease plugin and theme creation. Also this would result in it being easier for companies to integrate it with their current business. Project Details:

The current source code of phpMyAdmin is messy and hard to follow. A nice OOP class structure would clean up the flow of the website quite nicely. It would require porting the existing code into the new class structure proposed in the PMA developers wiki. Each class gets broken down to a small set of methods and properties and from there, they extend each other creating small classes that work nicely together. This results in a cleaner code structure and hopefully a stronger community working on it.

Porting PMA to OOP would have at least these benefits: Reusability: Each object is developed to solve a specific set of problems. So when other developers suffer from the same set of problems, classes can be incorporate to projects without affecting the existing workflow. Refactoring: When you need to refactor your projects, OOP gives you the maximum benefit because all objects are small entities and contain its properties and methods as a part of itself. Extensibility: If you need to add features to your project, you can achieve best results from OOP. You can refactor your object to add a feature. While doing it, you can still maintain backward compatibility of this object so that it works fine with an old code base. Or you can extend the object and create a totally new object that retains all the necessary properties and methods of the parent object from which it has been derived, and then expose new features. Maintenance: Object oriented code is easier to maintain because it follows somewhat strict coding conventions and is written in a self explanatory format. For example, when a developer extends it, refactors it, or debugs it, they can easily find out the inner coding structure and maintain the code time after time.

General Coding Conventions that I will follow: In a single php file, there will never be more than one class at a time. Out of the scope of that class, there will not be any procedural code. Every class will have a proper name. For Example PMA_List_Database_Mysql_3 would be found in ./libraries/list/database/mysql/3.php Camel case will be utilized while naming the classes. The first letter of the major part is always a capital letter and the rest are small letter. For example a class named "arrayobject" will be more readable if we write ArrayObject. Properties or class variables will follow the same convention. While writing the name of a method, it will start with a small letter and then the rest are camel case. For example, a method to send an email could be named as sendEmail.

Deliverables:

A ported version of phpMyAdmin with a new directory structure and a new class structure. The new directory structure would be something like:

contrib -> stuff contributed by users html js -> All of the javascript libraries would go here themes -> with having a new OOP structure themes would be much simpler lang -> All of the language files allowing PMA to support several languages libraries ->the heart of pma where the classes for OOP reside scripts -> misc. scripts relating to pma test -> scripts for testing PMA

The new class structure would follow the one found on the PMA dev wiki: PMA *PMA_Config *PMA_Theme *PMA_Theme_Manager *PMA_List **PMA_List_Database ***PMA_List_Database_Mysql ****PMA_List_Database_Mysql_3 ****PMA_List_Database_Mysql_4 ****PMA_List_Database_Mysql_5 ***PMA_List_Database_OtherDBMS **PMA_List_table **PMA_List_Server **PMA_List_Column *PMA_Cookie *PMA_Url *PMA_Server *PMA_Database *PMA_Table

Project Schedule:

Week I Port PMA_Database over to OOP Port PMA_Server over to OOP Week II Port PMA_List over An abstract class to be used for PMA_List_* Port PMA_List_Server over Week III Port PMA_List_Database over Another abstract class to be extended in PMA_List_Database_* Port PMA_List_Database_Mysql Interface for PMA_List_Database_Mysql_* Week IV Port PMA_List_Table Port PMA_List_Column Week V Make it so a user can login, sessions are working and they can list tables. Week VI (MIDPOINT) Fix anything that broke in porting the OOP and make sure it works with the current PMA_Theme and PMA_Theme_Manager Week VII Port PMA_Cookie Port PMA_Url Week VIII Verify that all the Cookies work with the new OOP structure Week IX At this point all the code should be ported into classes and from here I have to get all the classes to work with each other. Week X Soft Finish- Make sure that PMA has all the functionality that it originally did, only with a new Class Structure. Week XI Buffer Week - Hopefully done with porting the code over, if not continue working on it. Most projects run behind schedule so in order to be done in the 12 weeks, I'm planning on the last two weeks to be catch up. If in fact the code is done these last two weeks will be spent creating fixes from the bug tracker. Week XII (END) Buffer Week - Hopefully done with porting the code over, if not continue working on it. Most projects run behind schedule so in order to be done in the 12 weeks, I'm planning on the last two weeks to be catch up. If in fact the code is done these last two weeks will be spent creating fixes from the bug tracker.