PHP as a language can be considered a templating system, as in its root it was meant to modify HTML pages dynamically. The need for more structured templating systems arose as PHP applications have grown more and more complex, giving birth to much more specialized and focused solutions.

He illustrates with an object replacement example - parsing the template as a PHP script and replacing any objects found with the corresponding object property value.

PHP V5.3 is set to be released by the end of 2008, and many of the new features in this release have been in the planning stages for a few years. Originally touted as "PHP V6 without native Unicode support," PHP V5.3 has been developed into a feature-rich upgrade to the PHP V5 line. [...] In this "What's new in PHP V5.3" series, we'll look at these new V5.3 features, and see how they are used and how they can be used in your Web application.

In this first part of the series he talks about:

• Improved static method and member handling
• The _callStatic() magic method
• Dynamic static calls
• Late static binding
• Standard PHP Library
• Circular garbage collection

I've been tinkering with dumping PHP objects, and have found myself constantly running into a brick wall. The output from print_r and friends is fine in some contexts, but for larger structures, it would be nice to tidy the output up a bit and wrap it in some HTML.

His solution is to serialize the object into a string (keeping all related meta information) that can be passed around and parsed back into its original form for debugging. He's included the script that works bye taking in the string and manually parsing it back out into its parts into a useful array.

What follows isn't so much a PHP trick as a fix for something that really should work, but doesn't. Although the manual implies that the behaviour described below is specific to Zend Engine 1, all my tests were performed against Zend Engine 2.2, PHP 5.2.5.

His example compares making a new stdClass both with and without a reference on the it and var_dumps out the result. The method with the reference fails silently, however and isn't able to correctly assign it to the global. He recommends a work-around though - setting it directly to the $GLOBALS superglobal.

Last week we discussed the new Zend Framework extension and gave you a look inside its functionality. This week we take off where we ended last week, and delve into remote objects and Zend_Amf!

The tutorial walks you through the setup of a new project, the PHP code behind it and how to get the two talking back and forth through a RemoteObject. Screenshots and complete code are included.

Data objects, which provide an API for accessing and manipulating database tables, are one such tool. There are a number of implementations for data objects in PHP, most notably the popular PEAR DB_DataObject package. This tutorial focuses on one such implementation, the DB_OO2 package, showing you how it can significantly reduce your coding time when working with database tables.

The DB_OO2 package (PEAR) lets you set up references to your database tables as objects and interface with them by setting properties and calling standardized functions. Many of the PHP frameworks out there let you do this same sort of thing, but those are built in - this method lets you use the package wherever. ]]> Mon, 27 Oct 2008 10:28:12 -0500 http://www.phpdeveloper.org/news/11186 http://www.phpdeveloper.org/news/11186 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.

Solar_Registry is a class for storing singleton objects which are used usually for things like SQL objects and the response and request objects. Now what's interesting, is that in the new version of Solar a new configuration key registry_set was added for the Solar arch-class. You can use it to tell Solar to automatically add objects to the registry when it starts up.

He compares the two methods - manual loading and the automatic version and includes a "real world" example of loading up an SMTP object.

It's hard to imagine pushing the limits of object oriented PHP so far that your web servers choke, but the truth is those limits are reached faster than you think. [...] While replacing objects with arrays when possible makes things a little better, the most performance friendly approach involves appending strings. For your convenience, we've run some tests that measure page execution times and memory usage to create the following guideline to help you plan out what areas of your code may have to break away from an object oriented nature.

He shares some benchmarks of the memory use for different variable types - strings, arrays and objects - giving load times and the amounts of memory used. He mentions three workarounds that could help (unset, static methods and paging) reduce the memory consumption of your script.

I admit that these judgments are hard to make. I could be wrong, more or less. Type hints are probably useful when code becomes stable enough and at the boundaries between modules. But I still tend to avoid using them until I get an actual bug that might have been prevented by a type hint. Their usefulness is and has to be an empirical question. The purpose of using them has to be catching errors earlier, so if they don't have that effect, there's no point.

He lists three reasons why he had given up on type hinting before, one being the limited usefulness when it came to objects. Applying it to scalars is a different matter, though, and can prevent improper passing of array/scalars when the other is needed.