Changelog:

- a bug about session name was solved
- FCKEditor was updated to 2.6.2
- a bug with shadows CSS was solved (unused shadow.png file is not linked by screen.css anymore so we’ve no “file not found” in web server’s logs)
- P4A_Error_Handler() global function now uses the P4A::messageWarning() wrapper for P4A::message() solving a bug with the warning icon name that was changed in 3.0.0-rc5
- jQuery UI was updated to 1.5.1

For the first time p4a is also available as .deb package. We encourage all users of Debian based distros to test this new package and give us feedback.

Download P4A 3.0.1

It was a long long journey started on December 17th, 2007, with more than 800 commits it has really been an hard work but we’re proud to tell everybody that P4A 3.0 is finally released!

Thank you everybody contributed to this wonderful release!

I suggest you to check the official release notes, they’re full of useful info and… For who was waiting… commercial license is available too.

Note: the image at the top is just a humorous revisitation of P4A logo with some “300 the movie” effect :-) hope you enjoyed.

1) prerequisites

First of all we’ll install the php5-dev package which contains some utilities we’ll need for the build process:

sudo apt-get install php5-dev

then you’ve to find out your ORACLE_HOME environment variable, try executing:

env | grep ORACLE_HOME=

If this command outputs something like:

ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

then you can jump to section “2) Getting and compiling PDO_OCI” otherwise go on thru this section.

If this guide we’ll just see how to find out which is your ORACLE_HOME directory if you’ve installed the oracle-xe server package. If you’ve installed instantclient or anything else please refer to the product documentation. So you’ve an installed and configured oracle-xe instance on your machine, now type:

cat /etc/init.d/oracle-xe |grep ORACLE_HOME=

the command should print something like:

ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

now we’ve to export this variable to the current terminal session, we’ll do that with this command:

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

and the environment variable will be configured.

2) Getting and compiling PDO_OCI

Just cut and paste these simple commands to download PDO_OCI from the web and prepare it for the build phase:

cd /tmp
pecl download pdo_oci
tar xvfz PDO_OCI-1.0.tgz
cd PDO_OCI-1.0
phpize
mkdir include
ln -s /usr/include/php5/ include/php

now everything should be setup and we can build the driver and install it with:

make && make install

If everything is fine you can continue

3) Configuring PHP and Apache

if everything is fine you can go on editing your php.ini file and adding this line:

extension=pdo_oci.so

now create a phpinfo.php file under your apache’s document root, containing this line:

<?php phpinfo();

point your browser to:

http://localhost/phpinfo.php

and search for the “environment” section, it should look like the one in the next screenshot:

if you see the ORACLE_HOME line everything it’s ok, jump to the “4) Closure” section otherwise edit /etc/apache2/envvars file and add the ORACLE_HOME configuration, it will be something like this (on a single line):

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

4) Closure

Restart your apache and you’re done:

sudo /etc/init.d/apache2 restart

Zend Framework has a quite impressive Zend_Date and Zend_Locale modules which finally do things we needed 4 years ago with MerlinWork and then P4A, like normalizing localized dates and parsing the Unicode’s Common Locale Data Repository but I think we still need a good calendar module that would do the things that Pear::Calendar does now. I’ll post an issue to Zend ASAP.

• I’d hire 5 programmers to finish PHP unicode support in 2 months
• I’d hire 5 programmers to clean up the database drivers and fix some PDO problems within 4 months, so also PHP could have a great DB interface like jdbc or ado
• I’d hire 2 programmers to add a full abstraction layer to Zend_DB
• I’d drop the old Zend Studio and focus on Eclipse PDT
• I’d start a PHP development blog, people need to know where developers are going

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.

Once upon a time PHP had several different DB drivers such as:

• 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.

There are mainly 2 PHP abstraction layers out there:

• 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…

It seems to me that none in the world needs to get meta-info from a query like this:

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.

This post is nothing more than a reminder to me, ruby.NET is out today, Microsoft is working with Zend to build PHP.NET, is bigM trying to catch developers working with open languages? This surely mean that these languages gained (with python) so much audience and respectability that no one should ignore them.