-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Edouard,
2010/3/25 Edouard SWIAC edouard.swiac@gmail.com:
HI Michal, Le 25 mars 2010 à 09:44, Michal Čihař a écrit :
Well the thing is that both mysql/mysqli drivers in phpMyAdmin share fair amount of code, so it's not that much of code to maintain (not that it requires much maintenance at all). Moving to PDO is about new code to write and test and introduces another dependency (I have no idea how common is to have pdo enabled on hostings). We might end up having PDO in addition to current interfaces and I really don't see benefit of this situation.
I discussed PDO related ideas with Marc , and these have been put aside for a GSoC project. Otherwise, I think a good OO PHP introduction in PMA is a complete rewrite of a single module (say Export or Import or both), with some well-thought classes behind it (could be PMA_Table, PMA_Database, PMA_Rowset ...) that, used with existing classes (PMA_List_Database ...), would be used as a foundation for the rewrite of the other part of PMA, since everything cannot be rewritten and redesigned by one student in one GSoC. For example, in the case of the Export module rewrite (even Import), this rewrite should offer a documented OO common interface : "Give it a query, PMA returns a Rowset object, use it in whatever representation you want in your own plugin". This concept is thought in the way of modularity and third-party plugin development (as said in the OOP GSoC project). If think I'll head this way for my formal submission.
I agree that Export is a good candidate to rewrite in OO, for several reasons :
* It's a stand alone module, nothing major depends on it (I think). * It's well suited for an OO approach, as you can create an abstract export class, and then create specific classes (for PDF, SQL, ...) that derive from that class. The export functionality then uses the (abstract) export class, and depending on the instance, the right output is generated. (The concept is called polymorphism if I'm not mistaken)
The import-module can be conceived in the same way, I mean : basic functionality that uses the abstract class, with derived classes for specific types (SQL, csv, ...). But I'm wondering if it might be useful to combine the export/import classes into one class? To keep a better overview it's maybe better to keep the import and export classes separate.
Creating PMA_Table, PMA_Database, PMA_Rowset,... classes is a good idea. But this is will be more difficult to merge. The PMA_Table class already exists, but can not be used as an instance at this moment, because it is more or less a collection of functions. Converting it to an object is a possibility, but you have to take care that the static calls (without using an instance) throughout the code still work. Rewriting the entire project to use the PMA_Table class as an object, is a bit too big for one GSoC project, I think. Maybe you could convert the PMA_Table class to something that can be instanciated, but still works when used static. Or maybe a new Table (together with a Database, Rowset, ...) class should be created, to start using as an object in your export/import module (and later in the rest of the project.
But these are just ideas.
Kind regards,
Dieter
Edouard
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel