Hi!
Thanks for your reply Marc, I'm back with some idea for this GSoC project now .
Instead of directly talking about PHP OOP architecture, I would like to speak REST
architecture style firstly. I designed and developed a RESTful web service for the last
company I worked for as an intern (4th french online shoes shop), and I developed a PHP
RESTful proxy.
Beyond the buzzword, it's a well-organized and extensible architecture, that fits very
well with PMA. PMA is seen as a GUI that helps manage a MySQL server, but it also can be
seen as a web service (disguised beneath a GUI though), transferring and building
comprehensive data between the MySQL server and a end user. Plus, relational data is very
prone to be REST oriented.
Why should one consider PMA as a REST oriented app ?
-Client/Server architecture
PMA is the client of an underlying application, MySQL, querying on behalf of the user.
- Resources
Everything that comes from the server and the user work with (CRUD) can be considered as a
resource : a table, a row, a user ...
SQL queries change the state of theses resources, switching them into a new state.
- Uniform interface
CRUD operations in DBMS are similar in nature to what HTTP methods do to resources
(GET/SELECT, POST/INSERT, DELETE/DELETE, PUT/UPDATE ...).
- Resource representations
Dumping data from a table is basically dumping the application state : one can select the
representation he wants : CSV, LaTeX, XML, PDF ...
-URIs & Stateless
Clean URIs such as /tables/myapp/users?first_name=Elvis&last_name=Presley are easily
bookmark-able due to their stateless structure, and editable by experienced users via the
browser's address bar for fast and simple access. Obviously it can support SQL queries
and representation types like /tables/myapp?query="SELECT * FROM users WHERE
first_name='Elvis' AND last_name='Presley'"&output=xml. In this
example, since a URL is fetched via GET, only SELECT statement should be allowed (DESCRIBE
too, but querying via URL is just a utility tool, not a full API).
There is some points on which PMA cannot be RESTful (REST oriented is enough), since it
cannot handle cacheability (we need live data) and maybe some others I miss since I do not
know every internal requirements.
That was my thoughts on the non-code oriented architecture topic. Now let's move on
PHP ;)
Should the new architecture be PHP 5.3 compatible and leverage its new functionalities ?
As you now, Zend and Sensio headed their frameworks' next major version toward PHP
5.3. What are your plans about it ? (PMA 3 being young)
Currently, PHP code is very tied to HTML code and no template solution is used. GSoC
proposal says it should be easier to create new templates, so maybe we should start with a
simple template engine (existing or home made) that users can learn easily. Pro and cons
should considered : home made template may be faster and better integrated, but users have
to learn it and documentation has to be written for example ... This separation of
concerns leads to MVC architecture, which is currently the best architectural pattern for
PHP web based app.
Whatever happens, an OOP structure for PMA means a big rewriting of its codebase if
I'm not wrong (although some classes are already in the place) . A modular approach,
with low coupling components (observer pattern, maybe DI ?) should allow code reusability
and easy plugin development.
Concerning mysql drivers, what are your minds on PDO ? Actually mysql_* and mysqli_* are
the two interfaces used. PDO offers some nice features (prepared statements) for an OO
environment (Exceptions) and some little tiny ORM possibilities (Object hydratation-like
with fetchObject).
Finally, testing could be introduced, to ensure only error free code is committed (not
saying you commit code with errors :p) and that it won't break any existing
functionality.
I hope my ideas is not too far away from your expectations, and that some of them will
grasp your attention.
Regards,
Edouard
Show replies by date
Edouard SWIAC a écrit :
Hi!
Thanks for your reply Marc, I'm back with some idea for this GSoC project now .
Hi,
I believe that such an architecture change (REST) is beyond the scope of
a GSoC project. I even believe that such a rewrite might be so different
from phpMyAdmin that it should be a distinct project.
About the change of minimum PHP version, well, in the field things are
different. Last week we had about 4000 downloads of phpMyAdmin version
2.11.10.
About PDO, the last time I had a look at it, there were no practical
reasons to support it.
About testing, well, we already have a /test directory in our codebase
but it's limited.
--
Marc Delisle
http://infomarc.info