Michael Girouard has posted his 10,00 foot view of the typical structure of an Model/View/Controller application (and framework) and how a page request is handled:

In my previous article, I announced that I would be documenting the process of developing a simple MVC framework. In this post I will go into a little more detail about each of the specific components of our MVC and will discuss the series of events which occur each time a page loads, otherwise known as the page load scenario.

He talks about how URIs work, the role of mod_rewrite, several of the objects involved (like the Front Controller, Request, Route and View) and how they all fit in with the custom Models, Views and Controllers the user could define.

As mentioned on the Zend Developer Zone, there's a new tutorial posted on the IBuildings blog (by Lineke Kerckhoffs-Willems) about performing some multi-threading magic in PHP with the help of cURL.

Each PHP request is a separate thread. There are some workarounds like using pcntl_fork, starting multiple commandline php processes using the exec command or even using ajax. Another possibility is using the Curl library. Besides the basic functions described above Curl offers the "multi" functions for retrieving content from several url's at the same time.

Examples are included showing how to make these "multi" requests via PHP's cURL support (calling URLs with a "seconds" value on the end).

On his blog today, Stoyan Stefanov has a howto posted on a trick he figured out to get a PHP script to grab data from multiple resources at one time - with cURL.

The basic idea of a Web 2.0-style "mashup" is that you consume data from several services, often from different providers and combine them in interesting ways. This means you often need to do more than one HTTP request to a service or services. [...] Using the curl_multi* family of cURL functions you can make those requests simultaneously. This way your app is as slow as the slowest request, as opposed to the sum of all requests. And that's something.

He includes example code that loops through a given array of resources and executes the fetch, brining the results back into a result array. To illustrate, he also includes two types of examples of fetching content - one for GET and another for POST.

On the PHP in Action Blog, there's a this post that shares some tips for testing your web applications with some simple tests.

I just started listing the techniques I've learned when writing tests to exercise the web interface of a PHP application. This is from my experience and my personal preferences; it's not the final word or necessarily right for everyone.

He suggests:

• Use SimpleTest's Web tester if you can
• Test the web output using regular expressions
• Use element IDs or names to test links, forms and fields
• Log HTTP requests in the application

In one of his recent blog entries, Brian Moon takes a look at what he considers the "proper use" of the PHP superglobal $_REQUEST (as brought on by a thread on the PHP internals mailing list.

I have seen more than one person make the following logic mistake: I may get data via GET, I may get data via POST - Ah, I should use $_REQUEST as it will catch both.

Brian points out the error - cookies aren't in $_REQUEST so improper handling of those values could lead to cookie data overwriting GET/POST data from $_REQUEST. Several of the comments on the post also warn against improper handling of the values, noting that doing so could lead to holes open for attacks (like session fixation).

PHPBuilder.com has posted part three of their series looking at building a simple site using PHP and Ajax - this time with a focus on using the POST method instead of GET to push the data back and forth from client to server.

The advantage of this is primarily security, however you often can send larger amounts of data with the POST method as well (but that is dependent on your server configuration rather it be Apache/PHP, Microsoft/IIS, or Java/J2EE, etc). The primary advantage of POST is again, the security of the communication, because often log files on the web server will log the AJAX GET request data because that data is part of a URL in the request. This does not occur with the AJAX POST request.

They start with a simple example of the POST request type, pulling data from a form (address/city/state/etc) and pushing it to the backend script. They follow this by picking it apart, explaining each of the sections of code for a better understanding.