phpMyAdmin

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@... 
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel


-- 
Marc Delisle
http://infomarc.info

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

Edouard SWIAC a écrit :
> 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.

Hello Edouard (and other would-be students),

on this list we can discuss ideas but your formal proposal to be a GSoC 
student mentored by the phpMyAdmin project should not be sent to this 
list; you will send it on the http://socghop.appspot.com interface.

Your formal proposal will need to contain a clear plan of the tasks you 
expect to do in the eleven weeks (plus one week to scrub code). These 
tasks need to produce code that is tested (by you) and testable (by the 
community).

Especially, the *scope* of your proposal will have to be clear. For 
example, if your proposal is to change *all* phpMyAdmin codebase to OO 
and at the mid-term you have not succeeded into changing half of the 
code, you will fail your mid-term evaluation and Google will eject you 
from the program.

"Separating the presentation tier from the logic tier" is too vague; 
again, the proposal will need to contain the intended scope.

I have seen proposals where the student tells us that he wants to take, 
say, three weeks to familiarize himself with the code base. No can do.

We also have to look if the code produced by all students will be 
mergeable and will fit together.

P.S. http://wiki.phpmyadmin.net/pma/GSoC_2010_Student_Checklist

If this checklist needs improvements, tell us!

Regards,

-- 
Marc Delisle
http://infomarc.info

Hi

Dne Sat, 13 Mar 2010 13:18:28 +0100
Edouard SWIAC <edouard.swiac@...> 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.

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.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.

Edouard

-----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@...>:
> 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&#174; 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@...
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>
>



-- 
Groetjes,

Dieter Adriaenssens

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@...> 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 SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkurVTcACgkQ3DVS6DbnVgR/pgCfU+ebVQdQ5Szrx8yASY2h4TQf
qjYAoLoHE2j+joDsi5Erv6MwCnH0ghSm
=WF4h
-----END PGP SIGNATURE-----

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

Hi Michal,

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

iEYEARECAAYFAkurZ/4ACgkQZGJbiPqZM6MMUwCeMVQWfpggUbbJYbyl+ZLTmI3e
7AUAn2ugPx+xRegLlr/nZwwf6gKtZ7UQ
=lqWn
-----END PGP SIGNATURE-----

2010/3/25 Michal Čihař <michal@...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> Dne Thu, 25 Mar 2010 11:06:06 +0100
> Dieter Adriaenssens <dieter.adriaenssens@...> 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@...> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkurauIACgkQ3DVS6DbnVgTcegCfW3q0sIl2aPc9b9ybWm7Zjezw
YGIAoN2pm7GfijfVIrA+Ti+v+uTRdDBH
=S8i3
-----END PGP SIGNATURE-----