PHP Zend Framework and Oracle

Hmm, been ages since the last post, how time gets away - been pre-occupied getting my head around building applications in the Zend PHP Framework and hooking them up with Oracle. In other words, my recent love-hate relationship with the Zend Framework and Oracle!

The Zend Framework is relatively young, so while it is missing some features and documentation, it has an elegance and depth that allows some powerful re-use and extensions of Zend classes.

For example, being able to build forms on the fly based on either an ini file, xml document, array or xml loaded from a database is very cool. To also incorporate fancy ui functionality and validations with the Dojo integration at the same time is just fantastic.

Flexibility can often mean more code, so there are trade offs for the flexibility. The performance trade off may not be that big a deal, particularly with larger applications that are easily modularised with Zend, and taking full advantage of caching using the Zend_Cache class in conjunction with a backend opcode cacher such xcache.

The documentation makes for a steep learning curve though, especially if you are used to something well documented like Codeigniter. As another developer said after reading some information on a zend class, "OK, it is great that the class can do all that, but how? Where do I find the detail? Are there any examples?"

At this stage, the only real practical answer is by looking at the Zend Framework source code. It has not been around long enough to generate enough quality sample code to learn from, though there are some nice samples starting to pop up. Also, the framework itself has frequent and significant changes which may work slightly differently in older samples, particularly if samples used incubator components.

A big benefit though particularly over time, is that rather than the documentation being a separate, after the fact set of html pages, the documentation is highly structured, and makes strong use of standardisation and docbook formats.

The completely optional but highly structured modular layouts of the file system determining class nomenclature (and vice versa) drove me completely batty, and I still don't get some of the relationships of class to location. My logistics background keeps screaming that putting logic in a name or identifier is the way to madness!

I also spent quite a bit of time fighting the framework sometimes. Abstracting everything to the nth degree, heavy use of the PHP5 object orientation capabilities, made me want to scream "come down outta the clouds and let me write some simple crap code that I could copy and paste into every function in every class file". So it taught me quite a few things as well.

Some things though are not so elegant, the Zend_Paginator for example is a really cool class for handling the pagination of data, and can handle arbitrary data not just database data.

Two items threw me though. I did not (and still don't) get why the Paginator can only use Zend.DB.Select being passed to it and not Zend.DB.Table, as both are similar abstractions for generating sql for retrieving data.

In fact you can supposedly create table joins with DB.Table as well as the DB.Select but at the time I didn't have any success doing this function. A moot point though as the paginator needed DB.Select classes passed into the factory method.

A little gotcha I found that maybe of interest to other oracle backend sites, is that the paginator generates the limit component of the sql statement with a column alias for counting the rows. OK for mysql, but depending on the installation and driver for Oracle, Oracle takes the generated sql, turns the alias into upper case, and then the paginator cannot find the column. The fix was just changing the constant string for the rownum alias.

Extending the DB.Table class is actually alot of fun, and is fantastic for extending the functionality of tables in a database where you need a database agnostic way to apply common insert, update, delete or even select functionality such as adding a calculated column or automatically setting column values instead of using triggers. eg setting the userid of the web user logged in, rather than the account used by the application to login to the database.