In the P4A 3 roadmap post, I told you about a new widget rendering system… I didn’t post more technical info intentionally, I wanted to create a bit of suspense :) but I also wanted to do some tests before publishing news.

For P4A 3 we’d like to have a killer graphic with killer features (resizable widgets, border layouts, beautiful and powerful menu and so on) thus we looked to the biggest javascript frameworks out there: extjs and dojo. Both have great features and both have issues.

Extjs as really a killer graphic layout, and it’s released under LGPL3 (developers wrote some licensing notes that I can’t really understand… actually I think that those notes could conflict with LGPL3 itself) but it has not an open SVN and development is quite closed. Another note: only community support is for free.

Dojo is more polite with licensing and it’s released under BSD, but I don’t like the graphic layout too much and the way you’ve to code your applications writing a non-standard HTML with dojo-only attributes. It has some accessibility features.

Some considerations:

• In my tests I found bugs in both frameworks
• porting P4A to one of these tools is a “1 way road”
• relying the rendering layer to a 3rd party project means we’ve to 1000% trust this project
• these tools do not have a good print CSS support

We would have a 3rd option: continue on our road with quite standard HTML but rewrite our CSS from scratch with a CSS reset and a modular design which will give us better control.

I wrote extjs developers to know if they’re interested in a collaboration with P4A, I’m waiting for an answer but I’m looking for your considerations too, community it’s important to me, please let me know what you think and what are your experiences with those tools (or suggest others).

This is just my opinion working every day with PHP for many purposes since 7 years.

PS: Surely also SOAP support needs attention but it seems they’re working on it.

• mysql
• pgsql
• mssql
• oci
• sqlite
• odbc
• informix
• firebird

Later came

• mysqli
• oci8

and we already had duplicated drivers (also if they have some different optimizations/features)

Later came PDO and we had

• pdo_mysql
• pdo_pgsql
• pdo_mssql
• pdo_oci
• pdo_oci8
• pdo_sqlite
• pdo_odbc
• pdo_informix
• pdo_firebird

so now we have 4 drivers only for oracle (oci, oci8, pdo_oci, pdo_oci8) and 3 for mysql (mysql, mysqli, pdo_mysql) and anyway every driver is at least duplicated.

I don’t think this is the right way to go on, if PDO is here to remain, first all bugs in pdo should be solved and PDO features should reflect the single driver feature (I wrote about about that yesterday), then old drivers should be removed. Duplicated oci/oci8 driver should be unified too.

Now the situation is confusing and it’s difficult to test things against different drivers, tracking and solving bugs.

• PEAR::MDB2
• ADODB

I used both for long time within P4A and the conclusion is that none of them is good enough, because of feature lacks, bugs, communication difficulties with the team. I have to say that MDB2 code is much clearer.

But there’s something interesting coming out from the enterprise world: Zend_DB, really well written and planned, feature rich and with a good team behind, but as the team says “it’s not a full abstraction/portability layer” so why not fill the hole?

What’s missing:

• sequence emulation, creating a table on DBs where sequences are not implemented. PEAR::DB already did it since years. This approach is not the best if you look for performance but it’s perfect for portability.
• metadata retrieving from a query instead than a table. We can read columns and metadata from a table but what about a query such as “SELECT * FROM table JOIN other_table”? We need to know which fields are returned, the data type and the table name.
• metadata mapping between different db engines, building an abstraction layer between different datatypes on different db engines, something mapping MySQL tinyint(1) to PostgreSQL::boolean and so on. MDB2 and ADODB already do that thus adding this feature won’t be too painful.

I’m also thinking about the redundancy of db adapters in PHP5 but that will be the subject of another post…

SELECT * FROM table1 JOIN table2 ON (table1.id=table2.id)

I need to know from which table are the returned columns from. That’s not possible. It was possible with some old PHP DB drivers (not for all and I can’t understand why) but it’s not possible with PDO (and also Zend_DB does strange things about that but it’s very limited).

Let’s look at the situation, PDO has the PDOStatement->getColumnMeta() method but:

• This function is EXPERIMENTAL. The behaviour of this function, the name of this function, and anything else documented about this function may change without notice in a future release of PHP. Use this function at your own risk.
• Not all PDO drivers support PDOStatement->getColumnMeta().
• withit the returned data there isn’t the table name

I filled a bug some time ago and some developer add that feature for MySQL but they don’t understand that it’s needed for every DB adapter and it was already done by some old functions.

Maybe no PHP developer need such kind of abstraction.