[Phpmyadmin-devel] [GSoC] OO PMA project proposals

[Edouard SWIAC]

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