On the Query7.com blog, Logan has posted his opinion on how you should be doing your development on sites that are more than just one or two pages - you should be using a framework.

Frameworks should be used when constructing web applications. Any application that involves a database, forms, sessions, cookies or a remote service (such as Twitter or Facebook) will benefit from being powered by a framework. There is no need to use a framework for a website that has only one or two pages, nor for command line utility scripts.

He lists some of the common features frameworks provide including database abstraction, caching, form management, authentication and internationalization. He also includes some of the more general benefits you get from using frameworks like portability, shorter development time, application security, plugins/module support and the enforcement of good coding standards (depends on the framework, obviously).

On the Propel blog there's a recent post talking about how the age of autoloading might be ending and how namespacing could be the next logical step (or could it).

Autoloading in PHP is a great time saver. It lets you write concise scripts without the knowledge of the exact directory structure of the libraries you use. But with the arrival of namespaces in PHP 5.3, and the influence of Java over new generation PHP frameworks, autoloading is changing. In the near future, explicit autoloading will be ubiquitous, but with none of the advantages of the old style autoloading.

He talks about "the old days" when things were included manually through file paths, how that graduated to the SPL autoloading and, most recently, up to namespace autoloading. He shares code samples of how the namespace loading works and how you can abuse it to override current classes/functionality with your own. He points out one interesting correlation though - that the "use" keyword seems a lot like the "require_once" of way back when. He shows how the added verbosity of namespace usage can be a hinderance on frameworks, citing microframeworks specifically and showing one implementation that's non-namespaced next to another that is.

Evert Pot has a quick post about a suggestion mentioned at PHPBenelux related to using namespaces with older code.

If you're running PHP 5.3 and you have to use pesky old code that uses long class prefixes (yea, so, pretty much all PHP code out there), you can still make use of namespace features to shorten them.

He includes a quick example that shows the shift from using the traditional Zend_Controller_Action_Helper_AutoComplete_Abstract to an aliasing with the use/as to just reference it as AutoComplete.

In a new post to his blog Kevin Schroeder talks about a book he's written about some of the stranger things you can do with PHP - You want to do WHAT with PHP?.

You will not find another book on the market like it. Mostly because other PHP authors are not as crazy as I am. [...] In short, if you want a book that goes beyond the practical for the purpose of expanding your mind, this is the book for you. It is not meant to be a "cookbook", pre se. It is meant to, as Einstein put it, stretch your mind so that it does not return to its original shape.

You can see the table of contents [pdf] and a sample chapter [pdf] about working with daemons. Other topics covered include networking/sockets, streams, character encoding, debugging, profiling and good development practices. You can pick up your copy on the MC Press site and have it shipped in early September 2010.

In a new post to his blog Ivo Jansch responds to some of the recent comments about scoping in PHP applications with some thoughts of his own (someone spurred on by the Symfony project saying that "private is evil").

I don't care much about Symfony as I'm not a user, but it turned to a discussion on OO theory when Stefan defended the position by claiming that you 'should have the right to extend a class's methods if it doesn't support the use case you have'.

He also mentions the agreeing opinions of Marco Tabini and Travis Swicegood. Ivo gives an example of a piece of code that uses all three states - public, protected and private - as a use case for his later statements. In his opinion, removing the private/protected scoping from the picture only helps those looking to make it easier to derive information from the class rather than fine-tuning what can be called.

Be sure to read the comments on this one - there's lots of great thoughts from community members in there.

On the php|architect blog there's a recent post from Jayesh Wadhwani asking a question developers all over the world wonder every day - to use a framework or not to (and what's the benefit)?

A framework is usually thought of or defined as an underlying structure. You could imagine a wooden structure, sort of a skeleton when a house is being built. This provides a guide, structure and flow to build the house. A programming framework pretty much does the same thing. A programming framework provides for a structured and disciplined programming which results in a more consistent output from a programming team.

He talks more about some of the things that come with framework use like the utility and "housekeeping" code as well as code you know has been tested and used by other projects successfully (especially with something like the Zend Framework. Remember, though, there's bad that comes with them - a possible steep learning curve and overhead that could be caused by using the tools it gives you badly.

In this new post to the SitePoint PHP blog, Craig Buckler asks a question about one of the newest features of PHP, namespaces - are they really so bad?

PHP developers have been demanding namespaces for some time. As PHP applications have grown larger and more complex, namespaces have become essential to prevent code clashes. [...] Unlike C# and Java, PHP has to retain compatibility with non-namespaced code. That has been achieved and you can choose whether to use namespaces or not.

He includes an example of the method that was previously considered (the double-colon) and the final spec using the slashes.

NETTUTS.com has posted their list of the top fifteen "wonderfully creative" uses for PHP on your sites.

If you are familiar with the basics of PHP, then you're probably wondering how you can use it to make your website more appealing. The possibilities are endless, and you can write your own PHP scripts or implement widely available scripts from around the web. Let's get started with 15 creative uses for PHP for your website!

Some of the uses mentioned include:

• E-Commerce
• Graphical User Interface
• Building an Online Community
• Parsing XML Files
• Image Processing and Generation
• Create a PHP Photo Gallery

Others include templating, working with Flash and with one of the more popular PHP blogging tools - WordPress.

PHPBuilder.com has posted the seventh part of their "ABCs of PHP" series - a look at arrays and hashes.

An array is a list of a certain variable type, where each item in the list can be referenced by a unique index number, usually starting at 0. [...] Like any other variable type, PHP will automatically define a variable type and set it up for you when you start using it, however in most cases (and it's good practice) you should usually pre-declare your intention to use an array, especially if you don't know in advance what your going to be storing in it.

The article talks about what arrays are, how to create them, manipulating them with functions like array_splice and creating subarrays.

A little while back, this interview was posted to the echolibre blog where David Coallier got a chance to talk with Iarfhlaith Kelly (of webstrong) about their use of PEAR.

This web app has a huge potential (internationally) and is developed following a solid architecture. Being strong PEAR contributors we are of course happy to take a look at what helped the footprintapp.com team achieve such a great product. So I went ahead and asked a few questions to Iarfhlaith Kelly from webstrong.

They talk about time spent using the PEAR libraries, how its helped reduce coding and development time and what sort of packages webstrong makes use of (Auth_HTTP, XML_Parser, etc).