Supposing we want to render some HTML, do we want to inject the template engine in to the controller? Should the controller be responsible for knowing how to render the template? I'm not sure, but if I can have it not do it with minimal fuss, I think I'd rather it not. The full stack framework has the @Template annotation, which allows developers to assign a template to a controller and then simply return an array. If they can do it in the full stack framework, we can do it in Silex.

He includes the code for an example of a 404 handling page that uses the "convert" method to configure a route (path to a controller) for the currently matched route. He also shows the creation of a simple "CustomRoute" class and a "TemplateRenderingListener" to make it simpler to customize the handling and output of the request, all injected into the application's DI for later use.

I'm in a fairly unique position of being able to refactor an existing site that gets a moderate amount of traffic (~10k per day). Technically speaking, it probably does not NEED to be rebuilt from ground up, but as this is somewhat of a hobby project for me, I am choosing to rebuild it because I think there are significant long term benefits and because of the learning experience it affords me. [...] The solution that I've come up with, so far, is to create a single library whose sole responsibility is to handle system / business level interactions that occur. This API is completely segregated from any consumer facing frontend and de-coupled from any particular framework implementation.

Comments on the post are mostly supportive - they're in favor of the API-for-business-logic approach, but some recommend other methods than the single library attack. There's suggestions of using current frameworks to handle some of the "dirty work" involved in setting up the API and a mention of focusing on performance as well as functionality.

If you've been following me for a while, you've likely heard me use the term "N-Tier Architecture" before. Today's question comes from Arno. He basically asked "What is this N-Tier Architecture thing you keep talking about?"... So, to answer his question, a N-Tier Architecture is one that uses more than one tier. Of course there's more to it than that...

He talks about the idea of a "tier" and how, despite it being somewhat subjective depending on the application and the person talking, all agree that it's a separation in the structure of your app. He shows some common setups for a PHP-based application and explains the usefulness of a tiered architecture. He also includes a more real example that involves multiple languages and data sources and explains some of the downsides to the tiered architecture approach.

Over the years I've built many different types of websites. These range from being a few pages, to being very customized with advanced features. I've learned there is no clear definition in the best way to create a website. But I do think there are advantages and disadvantages to pursuing different methods. This article takes an analytical look at each option. Let's take a closer look at the different approaches in building a website.

He includes a brief summary talking about each method and mentions things like benefits and downfalls of the approach and what can be involved in their development.

When it comes to software architecture, stuff gets funny. First we learn everything about it at university. We learn to use it as a part of our main project plan. We learn how to do risk evaluation. [...] Since we didn't have a lot of experience with software back then, the resulting architecture is a badly done, but well documented. This style of software architecture is called "Enterprise Architecture" and usually done by consultants.

They talk about delivering software versus delivering documentation and list some of the actual common reasons software architecture turns out how it does including: "I read about it in a blog", "It worked for me once" and the idea of the "Golden Hammer" of standardized structures.

Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model's language, as it's intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).

Symfony2 features a brand-new Form component that, to my knowledge, supersedes most existing PHP form libraries in functionality and extensibility (not counting the still lacking, native JavaScript support). [...] The purpose of this post is to demonstrate that the Symfony2 Form component is perfectly suited for this requirement. Symfony2-specific functionality can be unplugged, leaving only the raw core dealing with form processing and abstraction.

The post is broken up into several different sections, each detailing a different aspect of this Forms functionality:

• It's influences from other frameworks
• Key aspects it provides
• Abstraction (reusable code)
• Extensibility
• Compositionality
• Separation of Concerns
• Model Binding
• Dynamic Behavior

Both a high-level architecture and low-level architecture are provided, showing you the internal flow behind the form handling. You can find out more about this component in the Symfony manual or peek into the code on github.

This article describes common pains and symptoms of bad dependency management and common techniques for dealing with project-wide dependencies. [...] For the purpose of this article I am talking about classes using other classes. To manage your softwares dependencies then becomes designing your software architecture such that the depencies are good. The following sections will talk about what's bad, with good being the absense of bad.

In his "problems" section he includes things like "it's easy to do wrong", "it's hard to get rid of", the "low rate of reuse in bad DI" and how bad DI can make for "untestable software". He points to a few packages (including PHP_Depend) that can be used to determine your dependency levels. His methods for "injection" include using the global scope (so bad), using injection in a constructor/setter, making a service locator (registry) and using a full-blown dependency injection container.

All techniques, tricks and gimmicks aside, managing dependencies is more about actual design than abstract design patterns. You yourself are responsible for keeping the number of dependencies as low as possible and designing your system such that access to dependencies is provided in a sane, understandable manner.

Today I needed to get a client application up and running on my local system. This application uses the Geoip PECL package, so I needed to get this up and running. This turned out to be slightly more difficult than just a PECL install, as you're missing some libraries by default, so here is my log of things to do to get it up and running.

He gives the complete list of steps his followed including downloading the source and his way around this "System could not load this extension" issue. The trick was to recompile the source with the correct architecture. By default his extension was built with i386 instead of 64-bit but updating some of the CFLAGS settings (and a few other environment variables) got things compiling correctly.

A plugin architecture allows multiple developers to work on the same application and let yet another person assemble their work later on. It allows the plugin developer to understand just his plugin API without having to understand all the details of the entire application.

He describes a few platforms that already have the concept of plugins including Joomla, Mediawiki and SugarCRM. He explains what a plugin architecture should be and what it shouldn't be. All of this is his first steps towards building a plugin-enabled compiler and virtual machine in PHP.