As it mentioned in the phpMyAdmin GSoC 2015 idea list, the project is majorly about refactoring the code base to object-oriented. But I’d like to take one more step. I am going to build a basic template system first, which is helpful for our refactoring process.
Simple template system
As the HTML response are treated as PHP strings now, it’s pretty horrible to maintain such a long-long string variable. We can never know whether the HTML in it is correct or not until we execute it. So our first task is to build a basic template system. It is not necessary to apply the template system to the whole phpMyAdmin project immediately, but we can use it to manage codes that we needed to refactor this time easily.
You can see the template branch in my fork for more detail:
It create a PMA_template method in libraries/template.lib.php and I’ve applied this feature to the designer module. Here is the commit information:
The designer module should be much “clearer” now.
It should be noticed that the template system is isolated from phpMyAdmin current codebase. That is, the introduction of template system is painless and it just makes it easier for us to refactor codes. After refactoring, the HTML strings should be moved out from the Table related scripts and form template scripts.
Object-oriented design and refactoring
Currently our logical functions are separated in files with “.lib” and “.class” postfixes. But most of these files are poor designed and needs to be refactored. As the idea list specified, the project is pretty huge and it’s open-ended. So I’d like to separate the task into three steps:
Build a source code dependency graph for files involved in the refactoring project
It’s worthwhile to make a detailed plan before we start working. That is, for this project, we need to build a source dependency graph with details of functions we needs to refactor. A source dependency graph should contains the following things:
- Dependencies of the function
- Callers of the function
- Classification of the function
- A brief description on the function
Since the project is so huge that we can hardly handle all of files in this project, we should control our scope in Table related functionalities in the project. During this duration, we will also create template scripts to extract HTML strings from php codes.
Packaging the relative functions into classes
After we building the source code dependency graph, we can safely move the functions into classes. We can apply some object-oriented design pattern in this step, but it just only a little. Actually, all we need to do in this step is just putting the functions into the related classes, just like the way figured out in the Table class:
We can reserve some procedural features in this step for convenience.
After the classes have been built, we need to refine them with some OO design patterns. For the Table class we have talked above, we can package the
$table parameters into the class as private members for re-usability. And the ways to refactor the class structures is depended on the features of specified class.
To make a class well-designed, we can apply following few steps for each class:
- Encapsulate relative variables to keep the API concise
- Pick redundant parameters in member functions and make them be private members
- Extract duplicated pieces of code and put them into member functions
But when we refining these classes, we should always remember that it’s important to keep the code base simple and clean. So we must not over-design these classes. Basically I think the factory pattern is good enough for our project this time.
- A simple template system
- A source dependency graph for relative files
- Well-designed, and OOPed classes