Sebastian De Deyne has a new post to his site showing the Laravel users out there a method for theme-based views in their applications using vendor namespacing in a multi-tenant environment.

I'm building a multi-tenant Laravel application. One of the requirements of the project is that every client can have their own theme based on their corporate guidelines. By default a few css adjustments will suffice, but some clients request a completely different template.

Conditionally loading a different stylesheet per client is pretty trivial, but in order to use a completely different view per theme you quickly end up typing the same thing over and over across various parts of your application.

[...] There aren't any huge issues here, but all together it feels like we should be able to do better. There are a few strategies to clean this up, but I just want to talk about vendor namespaces today.

He gives an example of a view setup that makes use of the current client/customer's namespace to define the path to the template. He found this leading to a lot of redundancy and figured out a better way: using namespaces. Namespacing is mainly made for package development but can be use here to create a "theme" namespace. This namespace can then be defined once and reused across the application without the need to manually build the template location string every time.

On PHPMaster.com Patrick Mulvey has written up a new tutorial looking at using the PSR-3 logging structure to make a basic logger for your application.

Logging is one of the most ubiquitous tasks encountered in PHP. We use logs to track error messages, record important events, and debug problems with our code. In any PHP project, the code is likely to be full of calls to a logging library which handles these actions for us. [...] To promote compatibility between logging libraries, the PHP-FIG group recently released PRS-3, a common interface for logger objects. In this article, I’ll discuss how the logger interface defined by PSR-3 allows us to write reusable code that isn’t dependent on any particular logging implementation.

He includes a quick introduction to the PSR-3 format, how to get the files you'll need to use it (via Composer). He includes some sample code showing how to make the basic email class with a logger injected for use. Since the Monolog logging project follows the PSR-3 format, it's an easy drop-in option. He also talks about using PSR-3 to avoid having logger dependencies with the "LoggerInterface". There's also a bit at the end of the tutorial showing you how to use the Adapter design pattern to "proxy" the logging calls to the class via a PSR-3 interface.

Ryan Gantt has a new tutorial posted to his blog today looking at one of the features in the upcoming PHP 5.4.x releases - traits. Specifically he looks at the horizontal reusabillity they allow for in your applications.

The ability for a class to inherit from multiple parents is maligned by many, but can be a good thing in some situations. For those working in PHP, multiple inheritance has never been an option; classes are limited to one parent, though they can implement many other datatypes through the use of interfaces. Interfaces can lead to code duplication in improperly-factored inheritance hierarchies. Even in well-architected hierarchies, multiple classes that implement similar methods can contain a lot of overlap.

He starts with a definition of what traits are and where their real usefulness is (as well as what should be the difference between a class and a trait). He gives an example of a typical hierarchy where two classes extend a parent but then they both need the same functionality. Code duplication's not a possibility and inheritance make run into exposure issues. Traits come to the rescue by dropping in just the feature you need when you need it. His example code shows adding some logging to a simple class via a "Logging" trait and a "Singleton trait" example.

On the Ibuildings techPortal today they've posted the latest episode of their DPC Radio podcast series (as recorded at this year's Dutch PHP Conference). This episode is Derick Rethans' talk on reusability.

This session explain a certain set of design issues for library code that either is often extended, or created with extending and inheritance in mind. There are many ways how a library can be designed to make it both easier to test, as well as for external developers to consume and use. This presentation provides techniques for doing so.

You can either listen via the in-page player or download the mp3 directly. Be sure to check out the other great episodes too!