New on DevShed today there's a tutorial looking at using one of the newer features of PHP, closures, as view helpers in a basic templating system.

In this two-part tutorial I'll be showing you, in a step-by-step fashion, how to use the goodies offered by closures in the implementation of an object-based, easily extendable template system. This system will allow you to embed anonymous functions easily into template files, and call them as typical view helpers, too.

He starts the process of creating the templating system by defining two interfaces, the View and DataHandler. Using these as a base, he creates an instance of the ViewInterface (a "View" class) that can set the template file to use, set values to be displayed and render the formatted output. Included is a basic template and how to use the View class to set values into it. The "render" method is called on the view and the HTML markup is produced. The closure comes in when they try to call a value "clientIp" that needs to do something more complicated than just having a string assigned to it.

On PHPMaster.com today there's a new post from Alejandro Gervasio about a part of the SOLID development methods - the Liskov Substitution Principle - the idea that objects should be replaceable with instances of their subtypes without a change to the architecture of the application.

Even when the formal definition of the LSP makes eyes roll back (including mine), at its core it boils down to avoiding brittlely-defined class hierarchies where the descendants expose a behavior radically different from the base abstractions consuming the same contract.

He includes an example with a "deleted scene" from the Matrix depicting an attempted override of the PDO functionality with a subclass that, unfortunately, does not match the original's structure/method definitions. The problem was in the difference between the method signature for the "query" method. It help resolve situations like this he recommends creating a "contract" in the form of an interface your code can implement, forcing it to conform to a certain structure. Using this, he provides a rewrite of the "PdoAdapter" class to match the original signature

In a recent post to his blog Jeremy Cook has a tutorial about using the Countable interface (part of the SPL) in your objects to make them play nicely with functions like count.

PHP provides a number of predefined interfaces and classes that can really make your life as a developer easier but which are often overlooked. The functionality offered by the Standard PHP Library (SPL) and the predefined interfaces is extremely cool and very powerful but very underutilized. [...] I thought I'd write a few articles with examples of how I've used these classes and interfaces in the hope that someone would find it useful. I'd love it if people felt like commenting with their own examples too. I'll start with a quick look at the Countable interface.

He includes sample code for classes using the Countable interface and defining the custom "count()" method inside. This method lets you define how the object will behave when something like count is called on it. His examples show returning the number of items in a private variable, determining the state of an object and including logic to only find valid data (like from a database table).

In this new post, Sameer Borate shows you how to use his Amazon BrowseNodes script to work with the returned data from the Amazon Advertising API.

The BrowseNodes tool automatically gets all the child BrowseNodes and their names. The program recursively traverses the BrowserNode hierarchy and returns all the BrowseNodes and their respective names. You can display the nodes on the console or save it to a CSV file. You can also include the library in your existing projects to process BrowseNodes.

You'll need curl support on your system to make it work. Several code examples are included showing how to grab a certain node, showing a list of nodes, saving the node information to a CSV, changing locales and getting the parent node for the current node.

DevShed has a new tutorial posted today looking to help you counteract the bad practice of wrapping procedural code in "class" constructs and provide some useful suggestions of how to avoid it.

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

On DevShed.com today there's the first part of a two-part series showing how to build self-contained validator objects that can be used to test the format of user input for validity.

In this two-part tutorial, I show why the use of static helper classes can be detrimental to building robust and scalable object-oriented applications in PHP (though you should take into account that the concept is language agnostic). I also implement a set of instantiable, fine-grained validators, which can be easily tested in isolation, injected into the internals of other objects, and so forth.

Their set of "concrete validators" are all based off of a validator interface/abstract class and check things like email formatting, floats, integers and URLs. Also included are a few examples of using the validators in a sample script.

DevShed concludes their three-part series about building an ORM in PHP with this latest article. It introduces the idea of dependency injection into the mix, showing how it can be used in the relationships between entities.

if you've already read the two installments that precede this one, it's probable that you're familiar with the inner workings of this sample ORM. In those chapters I implemented the ORM's data access and mapping layers, along with a simple domain model. To be frank, the development of this last tier is entirely optional; however, it's useful for demonstrating the ORM's actual functionality in the deployment of a blog program, which naturally will handle some "typical" domain objects, namely blog entries, comments and authors.

They share the code for creating proxy objects and, using a "poor man's dependency injection container" made from a factory method, interfaces and service classes to handle the results.

In a new post to his blog Lukas Smith proposes an idea for a loosely coupled interface setup that would allow for easier integration between third-party libraries and other applications.

Especially as for different libraries a different subset of the community could end up collaborating. Here I see 3 options: 1) each library bundles the interfaces (even though they sit in some common namespace), 2) each project asks their users to fetch the common interfaces from some other place 3) runtime "coupling". Option 3) doesn't exist today and is what this blog post is about.

He introduces the idea of a "spl_register_compatible_interface" method that would let you compare interfaces to see if they'd mesh. There'd still have to be a lot of communication between developers to make things match, though. He suggests three "practical issues" that libraries/tools would have to overcome to use a system like this - each framework has their own interface setup, the lead time for collaboration could be too much to be worthwhile, a lack of interest from some about collaboration and the idea of competing interface methods.

He's looking for feedback from the community on the idea(s) though, so go and leave a comment with your thoughts!

On DevArticles.com today there's a new tutorial posted talking about one of the more popular design patterns, the Singleton, and how it can be implemented in PHP.

Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

Joshua Thijssen has a recent post spotlighting a part of the Standard PHP Library (SPL) that implements that Traversable interface, the IteratorAggregate interface.

Together with its more famous brother "Iterator", they are currently the two only implementations of the "Traversable" interface, which is needed for objects so they can be used within a standard foreach() loop. But why and when should we use the iteratorAggregate?

He answers his question with an example - a book that contains chapters. With a normal iterator you'd have to define standard functions (like valid, rewind or key). Using the IteratorAggregate you can push items into an internal array (like chapters in a book) and call a "getIterator" method to get this set. He also takes it one step further and shows implementing the "Count" interface to make it easier to get a total count of the items in the iterator. Sample code is included to help clarify.