On PHPMaster.com today there's a new tutorial posted, the first part of a series, looking at the use of the Standard PHP Library (SPL) in PHP. In this first part of the series, Stefan Froelich looks specifically at two of the more common uses for iterators - working with arrays and directories.

When I first came across the term iteration and saw the overwhelming list of classes related to it in the SPL, I was taken aback. It seemed maybe iteration was too complex for me to grasp. I soon realized it was just a fancy word for something we programmers do all the time. [...] In the first part of this two-part series I'll introduce you to iteration and how you can take advantage of some of the built-in classes from the Standard PHP Library (SPL).

Included in the tutorial is example code showing how to use the ArrayIterator to work with an array and the DirectoryIterator to process the contents of a directory. He also briefly touches on a few other iterators like "FileExtensionFilter", "RecursiveDirectoryIterator" and "RecursiveArrayIterator".

In his previous post to the MaltBlue.com blog Matt introduced the concept of configuration-driven Zend_Form instances. He's back with a second part to the series, enhancing his original examples by covering some of the base-level form configuration settings.

Ok, this should have been part one, but irrespective, here's the second installment in zend form mastery with zend config - core form configuration. As the W3c Form spec says, there are 8 attributes applicable to forms.

These attributes, including "action", "name" and "onsubmit", can all be set easily in the XML-based configuration file. He includes an example of the full XML file to show how they all fit together (updated from part 1). You can see an example of the output here and can grab the source for the example from github.

In a recent post to his blog Jeremy Cook has gotten back into looking at some of the SPL functionality that comes with PHP. In this new post he looks specifically at the IteratorAggregate and Iterator object types.

After a bit of a break I'm finally able to get back to writing about the predefined interfaces in PHP. PHP provides two interfaces that allow you to define how your objects behave in a foreach loop: IteratorAggregate and Iterator. Before taking a look at IteratorAggregate I'll briefly discuss how we can iterate over objects in PHP 'natively' and what it means to be Traversable.

He introduces the concepts being being "iteratable" and "traversable". He then shows how to implement the IteratorAggregate (only one method required, "getIterator") and Iterator ("next", "valid", "current" and "key" methods required) in classes of your own.

You can find out more about these two object types (including more sample usage) on their manual pages: IteratorAggregate & Iterator.

Marcelo Gornstein has returned to his "IVR with PHP" series in this latest post (see others here and here). In this new post he shows you how to create a full flow of interaction for your callers:

The last article was about how to create call flow nodes for asterisk, using pagi and php, to easily create telephony applications. It's now time to add a layer on top of it, and create a complete call flow with several nodes.

He talks about NodeControllers to control execution flow, results from their execution, available actions and an example of creating a controller and adding nodes. He builds on this simple controller and shows how to handle a few actions including responding to user feedback, adding multiple menu options and some more complex logic using a closure to contain the functionality.

In this new post to his blog Gonzalo Ayuso has shared a simple SQL wrapper that he uses to work with his databases. It takes in an injection of the database connection component (a href="http://php.net/pdo">PDO) and provides functionality for inserts, updates, etc. with transaction support.

If we don't use an ORM within our projects we need to write SQL statements by hand. I don't mind to write SQL. It's simple and descriptive but sometimes we like to use helpers to avoid write the same code again and again. Today we are going to create a simple library to help use to write simple SQL queries.

It's a lightweight library that'd be good for basic uses, but when you start getting into something a bit more complex, something like Doctrine2 or Propel might be a better solution (or whatever your framework of choice has built in).

On PHPMaster.com they've posted the third part of their series looking at development around RESTful APIs. In this latest article they take an outsider's perspective and look at using services rather than creating one from scratch. (Part 1, Part 2)

Imagine it's a warm, sunny, summer day. You're just walking along, taking a leisurely noonday stroll, when all of a sudden you come face to face with a RESTful API. What do you do? How do you interface with it? Or, as those of us in the know would say, "how do you consume RESTful services?" That, my friends, is the subject of this article.

They mention using other tools (like components/features of common frameworks) to interface with the services, but end up using the curl extension to make a POST request to a service to add a few events to a "/summerschedule" resource.

In this new post from Anson Cheung, he shows you a way to easily create nodes in an eZ Publish-based application, importing content, XML and files/files.

Node creation in eZ Publish by using PHP is not well documented. However, when you encounter a large number of contents need to be insert periodically. You would ask is there any way to automate the content insert function with script in eZ Publish??? Any here I am going to summarize the way to achieve.

He includes the code examples showing how to:

• Set the creator
• Import generic content and attaching it to a parent node
• Importing some XML content
• Adding an image or file record that points to a local file

On Developer.com there's a recent tutorial showing you how to create a basic access control list in PHP (not in any specific framework). It allows you to define not only user permissions but groups and group permissions as well.

So, what are the advantages of an ACL model? The first advantage is security. Using this model will make your application more secure and less vulnerable to exploits. When securing any program, it is good to give to the user only the privileges he/she needs. That means that, for example, you should not give super administrator privileges to someone who will only manage website content. The ACL security model allows you to do just that. The second advantage is the easiness of user management. You can divide users into groups, while each group has certain access permissions. Also, you can easily add new user groups, delete the old ones or change group permissions.

They include the database structure you'll need to make the backend work (four tables) and the code to create an "Acl" class with methods to check a user+group for a permission, get the permissions for a user and get the permissions for a group. It's a pretty simple system and has a lot more that could be added to it to make it more robust, but it's a good start.

On the NetTuts.com (Plus) site there's a new tutorial focusing on aspect-oriented programming in PHP, a shift from the usual methods of development with the goal of "crosscutting" your classes/objects by weaving in extra functionality. Their examples of this method use the FLOW3 framework.

All modern frameworks (including FLOW3) push a lot of patterns into the software stack that do a great job at separating the concerns of your business logic; among them the famous MVC that is separating your logic into different layers. However, an application is not only built on business logic alone. As it grows, you may want to implement additional services, features, plugins or plugins of plugins. You surely don't want this stuff in your business logic! But what are your options?

For their example, they show how to implement a logger across your classes, taking it out of the actual code and implementing it in an aspect (at the "pointcut") by "weaving" it into a DocBlock comment with special annotations. They help you get the FLOW3 framework set up and show you how to "kickstart" a new project and work with its controllers and resources. They show you how to implement the Logging aspect and how to define it in your code (and where it caches the requests).

In this new post to his blog Michael Nitschinger shows you how to create a simple lexer to parse incoming content (like custom configuration files or anything that uses its own domain-specific language).

A lot of developers avoid writing parsers because they think it's pretty hard to do so. Writing an efficient parser for a general purpose language (like PHP, Ruby, Java,...) is hard, but fortunately, most of the time we don't need that much complexity. Typically we just want to parse input coming from config files or from a specific problem domain (expressed through DSLs). DSLs (Domain Specific Languages) are pretty cool, because they allow you to express logic and flow in a very specific and convenient way for a limited set of tasks.

He illustrates with an example based on the Lithium framework's routing engine and how it could parse a text file that relates a route to a controller/action combination. He creates a "Lexer" class that defines a few regular expressions to parse the incoming text strings for matches on things like whitespace, URLs and identifiers (words) and return each in the lexer's output.