Thanks for your observations Marc.
About PDO, the last time I had a look at it, there were no practical reasons to support it.
I think there is at least one major reason to support it (PHP version independently). Since PMA accepts two data access interface ,mysql_* and mysqli_*, using PDO would avoid maintaining these 2 interfaces in adapters functions (such as PMA_DBI_fetch_row ...). Moreover, mysql_* and mysqli_* API are so nearly identical, that almost the same code is written twice. As you know PDO handles these two drivers natively, lowering the burden of code to write and maintain.
Coming back to architecture, templating (currently is active discussion) is a good way to go towards MVC. What do you think about it ? From what I see in PMA source code, some parts are developed with classes (Confirm, Error, File ...), so the project may consists in pursuing this objective, in order to smoothly convert the procedural code base into an oriented one.
Regards, Edouard
Edouard SWIAC a écrit :
Thanks for your observations Marc.
About PDO, the last time I had a look at it, there were no practical reasons to support it.
I think there is at least one major reason to support it (PHP version independently). Since PMA accepts two data access interface ,mysql_* and mysqli_*, using PDO would avoid maintaining these 2 interfaces in adapters functions (such as PMA_DBI_fetch_row ...). Moreover, mysql_* and mysqli_* API are so nearly identical, that almost the same code is written twice. As you know PDO handles these two drivers natively, lowering the burden of code to write and maintain.
Edouard, I don't get your point. You want phpMyAdmin to require PDO support in order to work?
Coming back to architecture, templating (currently is active discussion) is a good way to go towards MVC. What do you think about it ? From what I see in PMA source code, some parts are developed with classes (Confirm, Error, File ...), so the project may consists in pursuing this objective, in order to smoothly convert the procedural code base into an oriented one.
I prefer not to tell in public my opinion about going MVC for phpMyAdmin.
Regards, 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
Hi
Dne Sat, 13 Mar 2010 13:18:28 +0100 Edouard SWIAC edouard.swiac@gmail.com napsal(a):
Thanks for your observations Marc.
About PDO, the last time I had a look at it, there were no practical reasons to support it.
I think there is at least one major reason to support it (PHP version independently). Since PMA accepts two data access interface ,mysql_* and mysqli_*, using PDO would avoid maintaining these 2 interfaces in adapters functions (such as PMA_DBI_fetch_row ...). Moreover, mysql_* and mysqli_* API are so nearly identical, that almost the same code is written twice. As you know PDO handles these two drivers natively, lowering the burden of code to write and maintain.
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.
Coming back to architecture, templating (currently is active discussion) is a good way to go towards MVC. What do you think about it ? From what I see in PMA source code, some parts are developed with classes (Confirm, Error, File ...), so the project may consists in pursuing this objective, in order to smoothly convert the procedural code base into an oriented one.
Well be it objects or not, I rather think the code needs to be split to smaller functional blocks. Having several hundredths lines in single function makes it hard to review and even harder to properly test.
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.
Edouard
-----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
Hello Dieter,
Le 25 mars 2010 à 11:06, Dieter Adriaenssens a écrit :
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)
Yes, that's the point!
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.
I agree with you, it's better to have a clear separation between both : Basically : - Export : Export class > Rowset > export plugin - Import : import plugin > Dataset > Import class > DB
Rewriting the entire project to use the PMA_Table class as an object, is a bit too big for one GSoC project, I think.
Absolutely. For my project I consider writing and using a PMA_Table class that meet my needs. But following the SOLID principle (http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29), the PMA_Table class should be open to extension and future development (rewriting in our case), and closed to modification.
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.
PMA_Table is already 1149,I fear that adding the needed non static methods inside will grow the number of lines ... I'll look into the problem and find a "compromise".
Thanks for your advices Dieter !
Regards, Edouard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 11:06:06 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
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).
Well SQL export is used in several other places (table move/copy and I think also some synchronisation or other recently introduced feature uses it).
- 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)
Right.
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.
They really do not share code (unless they use external library like php-excel).
- -- Michal Čihař | http://cihar.com | http://blog.cihar.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Michal,
2010/3/25 Michal Čihař michal@cihar.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 11:06:06 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
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).
Well SQL export is used in several other places (table move/copy and I think also some synchronisation or other recently introduced feature uses it).
Table move/copy uses similar logic, but it's not shared with (except for some core functions) or depending on export. (I would have to check the code to be sure, but I've made some changes to both and I recall it was seperate code) But it is a good idea to use modified SQL export/import modules to copy a database or table. (modification should be to generate an sql export with renamed database/table names). I'm not sure if this mechanism should always be applied for moving/renaming databases or tables. This can more easily be done with an ALTER statement, unless you move a table to another database of course. But this goes beyond the scope of Edouards proposal, but it might be a nice application of an OO-ified export module. ;)
I didn't know about synchronisation and other features relying on the export module.
Kind regards,
Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 14:41:18 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
Table move/copy uses similar logic, but it's not shared with (except for some core functions) or depending on export. (I would have to check the code to be sure, but I've made some changes to both and I recall it was seperate code)
It does use it. There are some other users as well:
$ git grep export/sql.php db_operations.php: require_once './libraries/export/sql.php'; libraries/Table.class.php: require_once './libraries/export/sql.php'; libraries/Tracker.class.php: require_once './libraries/export/sql.php'; libraries/Tracker.class.php: require_once './libraries/export/sql.php';
I didn't know about synchronisation and other features relying on the export module.
It was changes tracking (as seen above) sorry for mixing it up.
- -- Michal Čihař | http://cihar.com | http://blog.cihar.com
-
Dieter Adriaenssens -
Edouard SWIAC -
Marc Delisle -
Michal Čihař