Hello,
It's a great thing that phpMyAdmin is part of the GSoC this year! I presented myself some weeks ago, then discussed with Marc about some ideas on this project. Now I'm submitting these to all the developers.
Ideas on some this project - Separating the presentation tier from the logic tier (currently in discussion on the devel mailing list). Moreover, no presentation layer should be present in the libraries' modules. All presentation related files (header_*.inc.php and footer.inc.php) would leave the /libraries dir.
- In the PMA library, OO written modules could be loaded using PHP's autoloading capacities. Folders should be used to help organize the librairies folder, to restrict the number of files directly within /librairies and enforce modularity in the library structure.
- Every file that's present two or three times and more with the same namespace (server_*, select_*, tbl_*, pmd_* ...), both from / and /librairies could be grouped and namespaced in one or more static methods, to benefit from autoloading, decreasing the amount of file and the require/include to write. Files used directly in the presentation layer (as server_* in /), once class transformed, would be queried from the logic tier for the presentation tier, should a template system be adopted.
- All export and import related files (/libraries/export/* and /libraries/import/*)could be merged in an Export and an Import modules. These modules would offer a uniform interface to ensure that third parties and vendors file format implements the methods PMA needs to interact with to send and retrieve data, and are object oriented. This could simplify the addition of new export/import format by third parties/companies. Moreover, third parties libraries (such as tcpdf or PHPExcel) should be located within their related module directory and not directly under /libraries. Before that, existings export/import libs have to be rewritten in OOP to be compliant with their own module interface.
- Libs like common.lib.php have too much and various responsibilities (and responsibilities from other layers). Without stepping directly into OO code, these files could be breaked in more specifics libs. Obviously, a 'common' named file contains common functions, but I think it's too much functions in a single file. For exemple, common.lib.php = 2771 lines. math functions, mysql functions, 'templating' function, escaping functions, formatting functions, navigation functions, messaging function (PMA_showMessage has ~260 lines, big for a single function, too many responsibilities), date functions, pagination, cache management (that one could get its own class).
- Global vars and objects access. Sometimes 'global' keyword is used between related functions, most of the time it's $_GLOBALS, and I could bet that I saw a Registry somewhere, but can't get my hands on anymore. What are the rules you observe concerning the global namespace ? $_GLOBALS for now and Registry for later ?
I also checked the Feature Request on the tracker, but most of the suggested features are not "OO code" oriented.
I am open to discussion on every ideas above, and even more !
Regards, Edouard
Edouard SWIAC a écrit :
Hello,
It's a great thing that phpMyAdmin is part of the GSoC this year! I presented myself some weeks ago, then discussed with Marc about some ideas on this project. Now I'm submitting these to all the developers.
Hello Edouard (and other would-be students),
on this list we can discuss ideas but your formal proposal to be a GSoC student mentored by the phpMyAdmin project should not be sent to this list; you will send it on the http://socghop.appspot.com interface.
Your formal proposal will need to contain a clear plan of the tasks you expect to do in the eleven weeks (plus one week to scrub code). These tasks need to produce code that is tested (by you) and testable (by the community).
Especially, the *scope* of your proposal will have to be clear. For example, if your proposal is to change *all* phpMyAdmin codebase to OO and at the mid-term you have not succeeded into changing half of the code, you will fail your mid-term evaluation and Google will eject you from the program.
"Separating the presentation tier from the logic tier" is too vague; again, the proposal will need to contain the intended scope.
I have seen proposals where the student tells us that he wants to take, say, three weeks to familiarize himself with the code base. No can do.
We also have to look if the code produced by all students will be mergeable and will fit together.
P.S. http://wiki.phpmyadmin.net/pma/GSoC_2010_Student_Checklist
If this checklist needs improvements, tell us!
Regards,