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