NETTUTS.com has posted the third part of their series on creating a simple PHP5 framework today:
Now that we've got a basic framework (see part 1 and part 2 of this series), we can start thinking about integrating designs with our PHP framework. For now, we'll concentrate on the front-end design, including how we can make it easy to 'skin' our new framework.
This part looks mostly at the HTML and CSS for the presentation layer (the views) to make a simple two-column layout with some basic image and text content.
On the PHPClasses.org blog today Manuel Lemos has posted a look at ORM - what it is and how you can use it to improve your applications.
Object-Relational Mapping, usually referred as ORM, is a software development approach to treat data stored in relational (SQL) database table records as if they were objects. Basically we can create classes with variables that represent fields of a database table. To insert a table record you need to create an object of the class, assign the variable values, and call a function of the class that takes care of inserting the table record
He illustrates what it is (brief code samples) and some of the approaches that developers have taken to implementing it. He suggests, however, that they should truely be called ROM (Relational Object Mapping) libraries rather than ORM due to the fact that they map an object (the database tables) back in to PHP objects. He finishes with a list of a few ORM resources and libraries including the one that helps power the PHPClasses website, Metastorage.
Matthew Weier O'Phinney has another post full of Dojo/Zend Framework goodness today - this time he looks at making proper layer files by combining the two.
During my Dojo and ZF webinar on Wednesday, Pete Higgins of Dojo fame noted that I could do something different and better on one of my slides. This particular item had to do with how I was consuming custom Dojo build layers within my code. I contacted him afterwards to find out what he suggested, and did a little playing of my own, and discovered some more Dojo and javascript beauty in the process.
The improvement replaced the need for a manual commenting/uncommenting of an addLayer call with a bit of namespaced layers that, based on the environment, adds a dependency for the right file. One less manual process, one less thing to go wrong on deployment.
Henrik waves goodbye to the Zend_Db component of the Zend Framework in this new post to the ProDevTips blog - his new favorite is Doctrine.
It was long overdue but finally I've taken a look at Doctrine. And I'm blown away, bye bye Zend DB. [...] It's time to try and convey how awesome I think Doctrine is.
His example sets up a table definition and defines the associations between the columns for a "members" table. He defines a "city" table too and shows how Doctrine can easily combine the two and make selecting from and inserting into the tables simple.
The Oracle Technology Network has a new article posted looking at a basic application that combines the power of an Oracle database with the flexibility of the Symfony framework.
Where should someone who wants to learn Symfony begin? Project Symfony has a very informative and well-kept Web site, with extensive documentation. As it turns out, there is a book about Symfony and there are also numerous tutorials-unfortunately all of them created using a MySQL database. That is, in essence, why I decided to write this article about Symfony and Oracle. It's not a full-blown tutorial, but I hope it will be helpful to those who want to use Symfony with Oracle.
The sample application uses the latest version of Symfony, an Apache web server and the Zend Core for Oracle to install and configure the needed setup. The bulk of the tutorial is taken up with examples of how to tell the ORM layer of Symfony about your database tables and how to build the default classes from them.
Francois Zeninotto has posted a comparison of three different ORM (Object Relational Mapping) layers for PHP - Propel, Doctrine and sfPropelFinder (the last being a plugin of the symfony framework).
When it comes to ORMs, it's all a matter of preference. Is it, really? This post compares side-by-side the code required to perform some simple operations with three OO database requesting API. The purpose is to demonstrate that productivity, and not only style, can vary a lot depending on the ORM you choose.
He's worked up a long list of examples including methods to:
Retrieving an article by its primary key
Retrieving the latest 5 articles
Retrieving articles based on a complex AND/OR clause
Retrieving articles authored by people of a certain group
Retrieving an article and its category by the article primary key
Retrieving articles and hydrating their author object and the author group
Each one comes with their own (usually simple) code. His conclusions point out different "bests" of each - like sfPropelFinder being the "most magic" and that some of the limits of Propel are very frustrating.
We can expect big things from Davey Shafik in the coming months - he's been working on a book for php|architect about one of the more powerful bits of functionality in PHP - streams.
For about 6 months now, I've been itching to write a book on the PHP Streams Layer - one of my favorite features of PHP; and also one of the least known considering it's powerful abilities.
He describes his goal simply as this: to create the definitive resource for working with the streams later in PHP. It should be out sometime in the third quarter of 2008, so keep your eye out for it then.
A different sort of abstraction layer project has been started up and has already seen a few releases - Forage. As mentioned on Rob Young's blog:
Recently I've been working on a search abstraction library for PHP called Forage. The idea is to bring to search what we've had for relational databases for quite a while, abstraction.
On Friday I put up a preview release with three backends; Solr, Xapian and Zend Search Lucene. At the moment it has the bare minimum of features but there will be more soon. In this post I'm going to talk a little about the motivation for the project and then walk through a short example.
He talks about the need for search abstraction (integration and resilience to change) before getting into an example of some code that grabs the data from an RSS feed, passes it in to the Xapian search engine and stores it before looking it over for thier search terms ("yahoo microsoft").
Wez Furlong posted a request for comments to the php.internals and php.pdo mailing lists yesterday about a new ly proposed update to the current PDO functionality - PDO 2. He just wants to clear up a few things...
It became apparent over the past year or so that PDO has been a good and
valuable addition to PHP. [...] We believe that having direct involvement from the data access providers would be most effective, which is why we set out to try and get them on board.
There were three steps they would need to make to push things to version two (documentation, define scope/direction and organize data provider integration methods) and the proposal that has caused a huge stir in the community - the idea of requiring a CLA contributors would need to sign.
Comments to this point from the community include:
When we officially started on 5.2 in March of 2006, we had several goals. I think we achieved most of those. We also accomplished some unplanned things. Our hackathon (me and maurice slept about 8 hours in 4 days I think) at MySQL Conference 2007 helped a lot. Remember, you can help us get there again by donating to our fund.
Updates include a new template for the forum, new PAI layers and more hooks to call them, better MySQL support, improved bundled modules, a new announcement system and a new, restructured search functionality.
