Larry Garfield has posted the results of some of his research into popular PHP frameworks and projects and see how they handle their structure as it relates to the PSR-0 standard.

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

On the XpertDeveloper.com site today there's a new tutorial talking about something that can not only help the structure of your application but can make things more reusable in the end - abstract classes.

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).

Stuart Herbert's latest post in his "PHP Components" series looks at an optional but handy thing you can include in your component's package - web pages (be they a manual or other kind of information). This new post talks about where they should lie in the component's package structure.

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.

On the Leaseweb Labs blog there's a recent post looking and some of the things you can do to optimize Zend Framework and Doctrine when used together for database access.

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.

Artur Ejsmont has a recent post to his blog with some recommendations on how to structure a Zend Framework application and its dependencies to make it both easy to maintain and extend in the future.

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.

On the Smashing Magazine site today Brian Hoyt has some suggestions for you to use to keep your workflow organized when developing your applications (code, file structure, assets, database, etc).

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.

On the OpenSky blog today there's a new post about object oriented development and class structure. More specifically about how you should use interfaces and abstract classes if you want to truly lock down the methods of your classes.

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.

David Gardner has a suggestion for your development that he thinks can help keep things neat and tidy - using interfaces.

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.

Sometimes getting back to the basics is a good thing. Alan Skorkin has done just that in his latest post looking at the basics of URLs including their structure and what characters are allowed (or are special).

Several people made a valid point in response to that post [about fundamentals in software development], in that it is often difficult to know what the fundamentals actually are (be they macro or micro level). So, I thought it would be a good idea to do an ongoing series of posts on some of the things that I consider to be fundamental - this post is the first installment.

He defines the structure of a URL (the scheme, host, port, etc), reserved characters and absolute versus relative URLs and how they're usually used.

Brandon Savage takes another look at a popular design pattern - the registry pattern - and how he's changed his thinking on its use a bit on how (or if) it should be used in your applications.

Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval. [...] For me, over the last few months, I've discovered two reasons why I advise against the Registry Pattern: first and foremost, it discourages unit testing, and secondly, it discourages good design.

He goes on to elaborate on why these to things could be so detrimental to your code including the problems it can cause in tests being a point of failure and that it can make you application sloppy by giving you an unpoliced "bucket" to drop things in without any context to where they fit in the site.

So what's his suggestion to replace this bit of functionality and make things both easy to test and simpler to keep structured? Dependency injection.