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

[Dieter Adriaenssens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Edouard,

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)

iEYEARECAAYFAkurNY4ACgkQZGJbiPqZM6OMugCfZrJbtFLcqkOhccvlnDATNhaX
c4IAnA6VUByLMQ/KEB63Bi3Zo8pXatlB
=cf3W
-----END PGP SIGNATURE-----

2010/3/25 Edouard SWIAC <edouard.swiac at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>
>



-- 
Groetjes,

Dieter Adriaenssens