Very often I find myself writing input filters for large XML files using PHP. Common enough task; and PHP offer a great variety of tools to do this effectively depending on the situation. Unfortunately, almost as common is the lack of documentation for the aforementioned XML files. [...] I have looked around for a simple tool but I didn't really find a tool that gave me the quick and dirty overview I wanted. A year or so ago I finally wrote a small PHP class to analyze large XML files.

He includes an example XML file, the HTML output of the parsing and a sample of how to use the class to parse and output the XML structure, complete with some CSS.

The Pear Structures_Graph package allows creating and manipulating graph data structures. It allows building of either directed or undirected graphs, with data and metadata stored in nodes. The library provides functions for graph traversing as well as for characteristic extraction from the graph topology.

After sharing the one-line install, he shows how to create some instances of the package's Nodes and how to connect them to a graph and link them to other nodes. He includes a few examples - a simpler one with multiple nodes joined in a directed graph, another showing how to associate data with a node and how to query the graph for node connections and testing to see if the graph is acyclic.

As Drupal is in the process of considering how to restructure code to best leverage the PSR-0 standard, I figured it would be wise to take a quick survey of how some other major projects organize their code bases. This is not a complete rundown of every project, simply roughly comparable notes for those areas Drupal is currently discussing. I am posting it here in the hopes that it will be useful to more than just Drupal.

The projects he looked to for his examples were:

• CakePHP
• Symfony2
• Silex
• CodeIgniter
• Zend Framework 2
• Composer

For Abstact keyword we can say that, abstract is type of the class and class which we can't create a object of it. Surprised???? [...] Abstract class can be used some what like an interface in PHP. So basically we can implement class using abstract. We can't extend more than one abstract class while we can implement more than one interface.

They introduce you to the creation of an abstract class and show how to set up some abstract methods inside. These methods are required to be defined as a part of the extension in your class. One of the benefits they don't mention of abstract classes over interfaces is the ability to have methods in the abstract that are actual code, not just definitions of the structure (that's more of what interfaces are for).

I'm now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. It isn't very often that a component needs to ship web pages too, but should the need arise, here's how to do it.

He starts by defining what a "web page" could be (HTML, Javascript, CSS, etc) and gives the place in the hierarchy they should fit. When you use the PEAR client to install the package, these files are placed in the "www" folder of your PEAR installation.

In principle, the combination of Zend Framework with Doctrine is not too difficult. But first let's talk about the preparations. According to the author of Zend Framework, the default file structure of project can be a bit more optimal.

They start by describing this optimized file structure (moving the models out of the modules and into the library) and what you'll need to change in Doctrine's configuration to make this work. The post also includes examples of what the larger config should look like when the changes are made. They show how to extend the default Doctrine CLI tool to make a custom "sandbox" instance and show some tuning you can do on the Zend Framework side so it can optimally work with the new models.

I don't mean to be negative but I am not too happy about the web application structure that most articles and books present. In Zend Framework world controller seems to be the place when things get done. Controller is the workhorse and this is where all the logic seems to be buried.

He talks about the non-reusability of controllers outside of a web-based environment and the bad habits that can come from depending on variables of that environment. He's come up with a diagram of how he thinks a good, modular Zend Framework application should be structured where the emphasis is on Services, not web requests. He looks at database aware/agnostic services, working with models, third-party code and working with external systems. He also touches on the "V" and "C" in MVC, noting how the views and controllers still fit into the mix.

Perhaps in the past you've tried to build a more complex, cutting-edge website like [our example], and the project started off with great enthusiasm, but ended up in a nightmarish mess that you couldn't maintain. Your client lost interest when new features started getting too hard to add, and you started having to work late at night, tracking down bugs that you couldn't even find the relevant file for. After a project like that, it's not hard to see the relevance of a well-organized website project.

He talks about some general principles like "don't over-organize" and "don't mix aspects of the site" as well as some more specific things like a website size to structure recommendation and parts of a site and how to handle them - assets, stylesheets, javascript, the database structure/values and, of course, the code.

Every class has an interface, every class can be typehinted as a method argument, typehint lets you specify the collaborator requirements. Not every typehint is the same.

He includes an example of how, despite a "BankAccount" type hint, classes for different types of accounts can be created and methods from the parent can be overwritten. To help remedy the situation, he shows a more structured example that uses interfaces/an abstract class to define the BankAccount structure, setting requirements on the child class functionality.

This post was sparked by a very simple question from an ex-colleague: "Why bother with PHP interfaces?" The subtext here was that the classes themselves contain the interface definition (through the methods they define) and hence interfaces are not needed, particularly where there is only one class that implements a given interface.

He talks about two reasons he things that interfaces could be beneficial - they help you think about things "the right way" of planning out structure before implementation and that it makes things more "future proof" the code by forcing future elements into the same mold as the current use.