Robert Basic has a quick post to his site where he shows how to use partial mocks in Mockery, a useful tool for unit testing in PHP applications.

In dealing with legacy code I often come across some class that extends a big base abstract class, and the methods of that class call methods on that big base abstract class that do an awful lot of things. I myself have written such classes and methods in the past. Live and learn.

One of the biggest problems with this kind of code is that it is pretty hard to test. The methods from the base class can return other objects, have side effects, do HTTP calls…

He gives an example of a model that includes a method returning a database connection. In the child class of this the method that he's wanting to test includes a call to this method, making it difficult to test in isolation. He then shows how to make a partial mock of the child class that, be definition, returns a mocked PDO instance instead of the real PDO instance. All other methods will be passed through to the real class.

Michael Dyrynda has written up a post showing the Laravel users out there how to perform partial model updates making use of the "intersect" method.

Many Laravel developers would be familiar with the helpful only method found on the request object, which allows you to specify keys to pluck from the request. Not only does this simplify your workflow, it works quite nicely when completely unguarding your models by setting protected $guarded = [];

[...] For newcomers to Laravel, you might find this suggestion dangerous, but using only means you will only pass the desired input to your model irrespective of what was passed via the request itself. [...] Adam Wathan tweeted about an approach he uncovered whilst helping somebody out when approaching partial model updates.

He shows how the method works by starting with a traditional update method call that reassigns model properties based on input (using "has" checks to ensure the property exists). He then refactors it to use the intersect method and replaces about twenty lines of code with one. He talks about the differences between using only and intersect and offers a caveat to using intersect around preserving null values on properties.

Anna Filina has a new post to her site today about using subfolders for partials in Symfony applications and keeping them organized.

Symfony 1.2 - 1.4 expects all partials to follow this convention: templates/_partial.php. What happens when you need to organize your partials in subfolder? I tried a number of "Symfunky" avenues.

She tried a few ways - calling the helper with the include_partial method but it didn't resolve to the path she wanted. Next she tried a different path, but Symfony only interpreted it differently - and not the way she wanted. After a few more tries, she found a solution - using get_partial with a parameter that defined the subfolder to look in.

On the Unravel the Music blog there's a recent post about using memcached to held reduce the load on your PHP applications by caching certain parts of your pages.

Many framework and standalone PHP developers are given options to do full-page caching but partial page caching is rarely an option. Many times a sidebar or a footer that is loaded with dynamic content can be cached for 5, 10, or even 30 minutes without needing to read from the database again. This can drastically reduce the load on the server as query results for certain portions of your page are stored temporarily. [...] Memcached can store queries that have been processed and the bits of HTML that go with their presentation. Read on for a detailed example.

Once the memcache functionality is installed, its a snap to get right into caching your content. The two examples - pushing data in and pulling it back out - show how to cache a bit of HTML content to be used later.

The Zend Developer Zone has posted a new tutorial (from Matthew Weier O'Phinney) about a handy feature of the Zend Framework's view layer - view helpers that can be added in and reused across an application to do some pretty cool stuff.

A View Helper is simply a class that follows particular naming conventions, When attached to a view object, you can call the helper as if it were a method of the view object itself. The View object retains helper instances, which means that they retain states between calls.

View helpers can be use to do things like manipulate view data for more complex operations and carrying over data between two views, limiting the number of fetches that have to be done. He shows how to create a simple helper - My_Helper_FooBar - that just appends "fooBar " to whatever's passed in. He also talks about some of the default view helpers (like form fields), partials, the doctype() helper, capturing/caching content to be used later and the use of placeholders.

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

Pádraic Brady continues his series on working with Complex Views in the Zend Framework with this new article - part seven focusing on the Zend_View Enhanced method.

It's been a long, and hopefully interesting, road to Part 7. In this concluding entry to the long running, and oft delayed, "Complex Views with the Zend Framework" series I introduce the Zend_View Enhanced Proposal for the Zend Framework, elaborate on its operation, and provide some opinions on the ongoing debate over its implementation.

In this final entry of the series, he recaps previous concepts (like Partials/Layouts/Controllers/Placeholders) and how far reaching the Zend_View Enhanced component is. He also includes some of the helpers and interfaces he's proposed for the module including:

• Zend_View_Helper_Partial
• Zend_View_Helper_Controller
• Zend_View_Helper_HeadScript
• Zend_View_Helper_Doctype
• Zend_View_Helper_HeadStyle

He takes each of the concepts mentioned above and applies these different helpers/interfaces inside them, illustrating with some sample code as needed.

Pádraic Brady continues his series on working with Complex Views in the Zend Framework with this new article - part seven focusing on the Zend_View Enhanced method.

It's been a long, and hopefully interesting, road to Part 7. In this concluding entry to the long running, and oft delayed, "Complex Views with the Zend Framework" series I introduce the Zend_View Enhanced Proposal for the Zend Framework, elaborate on its operation, and provide some opinions on the ongoing debate over its implementation.

In this final entry of the series, he recaps previous concepts (like Partials/Layouts/Controllers/Placeholders) and how far reaching the Zend_View Enhanced component is. He also includes some of the helpers and interfaces he's proposed for the module including:

• Zend_View_Helper_Partial
• Zend_View_Helper_Controller
• Zend_View_Helper_HeadScript
• Zend_View_Helper_Doctype
• Zend_View_Helper_HeadStyle

He takes each of the concepts mentioned above and applies these different helpers/interfaces inside them, illustrating with some sample code as needed.

On the Metapundit.net site, there's a new (long) entry that takes a look at one of the programming styles, functional programming, and checks into its support in PHP. Unfortunately, it's mostly a swing and a miss.

I should just get this straight right off the bat: you can't really do much functional programing in PHP. Functions are not first class citizens and the equivalent of passing functions around is passing around strings or arrays and relying on convention. No really.

He goes on by illustrating the point that PHP can do this sort of thing but only up to a point. Once you start to get into anonymous functions and moving past things like the array_map function, you start to loose a foothold. The create_function function allows for a bit more flexibility, but still doesn't fulfill the requirements needed for full support.