13 Mar
2010
13 Mar
'10
3:18 p.m.
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
13 Mar
13 Mar
4:19 p.m.
Edouard SWIAC a écrit :
Thanks for your observations Marc.
Edouard,
I don't get your point. You want phpMyAdmin to require PDO support in
order to work?
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.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Marc Delisle
http://infomarc.info
25 Mar
25 Mar
11:44 a.m.
Hi
Dne Sat, 13 Mar 2010 13:18:28 +0100
Edouard SWIAC <edouard.swiac(a)gmail.com> napsal(a):
Thanks for your observations Marc.
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.
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.
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
12:18 p.m.
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
1:06 p.m.
-----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(a)gmail.com>om>:
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Groetjes,
Dieter Adriaenssens
2:53 p.m.
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
3:21 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 11:06:06 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)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 SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkurVTcACgkQ3DVS6DbnVgR/pgCfU+ebVQdQ5Szrx8yASY2h4TQf
qjYAoLoHE2j+joDsi5Erv6MwCnH0ghSm
=WF4h
-----END PGP SIGNATURE-----
4:41 p.m.
-----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(a)cihar.com>om>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 11:06:06 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)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)
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
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).
4:53 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 14:41:18 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkurauIACgkQ3DVS6DbnVgTcegCfW3q0sIl2aPc9b9ybWm7Zjezw
YGIAoN2pm7GfijfVIrA+Ti+v+uTRdDBH
=S8i3
-----END PGP SIGNATURE-----
5294
days inactive
5306
days old
8 comments
4 participants
participants (4)
-
Dieter Adriaenssens -
Edouard SWIAC -
Marc Delisle -
Michal Čihař