
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">HI Michal,<div><br><div><div>Le 25 mars 2010 à 09:44, Michal Čihař a écrit :</div><br><blockquote type="cite"><div>Well the thing is that both mysql/mysqli drivers in phpMyAdmin share<br>fair amount of code, so it's not that much of code to maintain (not<br>that it requires much maintenance at all). Moving to PDO is about<br>new code to write and test and introduces another dependency (I have no<br>idea how common is to have pdo enabled on hostings). We might end up<br>having PDO in addition to current interfaces and I really don't see<br>benefit of this situation.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote></div><div><br></div><div>I discussed PDO related ideas with Marc , and these have been put aside for a GSoC project.</div><div><br></div><div>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. </div><div><br></div><div>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).</div><div><br></div><div>If think I'll head this way for my formal submission.</div><div><br></div><div>Edouard</div></div></body></html>