Asmir Mustafic has continued his series looking at building modular applications with part five looking specifically at some of the considerations and ideas to keep in mind when developing your modular applications.

This is the fifth post from a series of posts that will describe strategies to build modular and extensible applications. In this post we will take a general overview on how some popular design patterns and things to keep in mind when creating plugin based applications.

[...] Anthony Ferrara (alias ircmaxell), in this post blogged about the use of software patterns to implement plugin-based architectures. It is a great article and I suggest everybody to read it. As it is clear from the article, each of this software patterns has a specific use case and the choice of which one to use depends on which the of integration we want allow for the future plugins.

The article starts with a brief recap of some of the more common design patterns including the Observer, Strategy, Decorator and Chain of Responsibility. It then covers some quick uses of these patterns and shares two tips when developing a plugin system for the application and links to good examples for reference.

Asmir Mustafic has kicked off a new series on his site with an introduction to modular application architectures. In the series he will work through the creation and management of modular applications as inspired by a session he attended in 2011.

When developing a software, one of the most common steps is taking care that the resulting application is extensible and modular.

Let's suppose we have our application or library. If we see it from outside, often it looks as a single thing. [...] As the application grows we can continue adding components... but this comes with a price. Components often knows too much of our application and there is a delicate equilibrium of dependencies between them and our application. When not handled carefully, a small change in one component might require changes in many other.

As a rule of thumb, I personally try to follow as much as possible the Acyclic dependencies principle Another way to allow extensibility but keeping the application "clean" is to introduce modules.

He starts by talking about modules and the major part they'll play in the overall architecture. He explains why modules are so key to the overall structure and what kind of advantages they bring along with their use. He spends the remainder of the post looking at some of the main challenges they'll face including the file/directory structure definitions, module registration methods and the configuration of each of the modules.

The SitePoint PHP blog has a tutorial posted from author Eugene Dementjev covering the use of "forwarding decorators" to create a more modular architecture for your application.

As your web application becomes larger, you certainly start to think more about designing a flexible, modular architecture which is meant to allow for a high amount of extensibility. There are lots of ways to implement such architecture, and all of them circle around the fundamental principles: separation of concerns, self-sufficiency, composability of the parts of an app.

There is one approach which is rarely seen in PHP software but can be effectively implemented — it involves using native inheritance to provide manageable patching of the software code; we call it the Forwarding Decorator.

The post starts out by defining the modular architecture and some of the basic concepts involved (including a flow graph or two). Then comes the examples - how as basic version of the system could be used, multiple modules modifying a single class and hooks/patching the code.

In a new post to his site Nicolas Widart introduces you to the idea of building Laravel applications a bit differently than you may normally: in a more modular structure. This structure makes use of this package to make it happen.

Let me start by saying Laravel is an amazing framework. However when it comes to writing more complex and bigger applications, I find the default structure laravel comes with cumbersome and not ideal.

The way the default laravel installation comes with is basically all the application logic inside an app/ folder. This works, but I would not suggest going this route. [...] This is what being modular is trying to resolve. You split of the business logic into different parts, which belongs together. If you're into Domain Driven Design, you can consider a module an aggregate.

Each module has its own resources (routes, models, views, etc) combined into a single "drop-in" structure. He provides an example of this structure and compares it to the more traditional Laravel "all-app" structure. The package he links to makes this modular structure simpler and points out that this system is what the AsgardCMS already uses behind the scenes.

PHPMaster.com has posted the third part in their "Practical Code Refactoring" series - this time with a focus on Extensibility. (Part 1, Part 2).

Extensible code is a piece of code which follows re-usable, logical, well-known patterns, be it standard design patterns, or normal logical flow. Modular code tends to be highly extensible and monolithic code tends to be non-extensible, but monolithic code might be more efficient, so to solve this conundrum some practices allow developing in a modular way and deploying in a monolithic way so we can get the best of both worlds. The major aspects which we are to discuss with regard to extensible code are: logical extensibility (normal logical flow and design patterns), modular design, and decoupling and encapsulation.

He goes through each of the sections - logical extensibility, modular design and decoupling/encapsulation - and for each provides some questions to ask to help you whip your code into shape.

Phil Sturgeon has a new post to his blog today for the CodeIgniter folks out there - a tip on keeping things organized by using git submodules for package management.

With CodeIgniter moving to GitHub we are starting to see a lot of CodeIgniter developers wanting to learn more about Git, specifically how they can use it to improve their workflows, manage their applications and move away from the horrible days of copying and pasting updated libraries off a wiki. UCK. Sparks are helping us on the whole, but there is another method that we can use to manage our packages: Git Submodules.

Submodules allow you to pull in source from a remote repository without having to merge the code into your own. It creates a dependency between the two and makes it easier to check out only what you need. He gives the example of his oauth2 package being needed in multiple other applications, so instead of including and checking in multiple versions, he made a separate repo and defined the source as a submodule. He also includes a bit about fixing issues in your submodules with a few handy commands to get on the right branch, add a remote and push the commit.

In a new post to his blog Phil Sturgeon has posted about a patch he's created to give the pre-release CodeIgniter 2.0 version the ability to do some Modular Separation.

The fix was worked out a few hours after CodeIgniter 2.0 was released but I was hoping wiredesignz would incorporate and re-post. Sadly the man has other commitments to attend to, so I have released the patched version.

The patch includes two files - custom libraries to extend from for loading and routing in your CodeIgniter 2.0 application. For a better understanding of what this patch gives you, check out this thread on the CodeIgniter forums.

On the Zend Developer Zone there's a new tutorial from Vikram Vaswani looking at creating templates for your website with the Savant templating engine.

Now, there's no shortage of template engines out there. You've probably already heard of Smarty, Template_IT, Flexy and Xipe...and that's just the beginning of the list. If you're looking for something a little different, though, consider Savant, the subject of this article. Although Savant isn't as well-known as some of the other options available, it's still a lightweight, OOP-compliant template engine that offers some unique features and is well worth a look.

He works through the templating of a sample site (using .tpl files) to create simple layouts and add in some more advanced features like assigning variables, using objects, looping and partial templates. He also shows how to use the filtering functions to manipulate the template output directly.

DevShed has posted the final part of their series on handling exceptions in PHP5 applications. In this part they wrap up the creation of their modular exceptions class.

By means of a hands-on approach, this series walks you through using inheritance to build finely-tuned exception subclasses. These subclasses can be used to handle, via multiple "try-catch" blocks, several failures that might occur during the execution of a given web application.

They show how to handle MySQL exceptions with two different subclasses - one for the MySQL connection itself and another for problems with the results. They then merge these two classes into one and show how to use the new hybrid creation in a sample SQL connection and query.

DevShed has posted the final part of their series looking at the handling of file uploads in PHP5. This last installment shows how to take what yuou've learned so far and make things a bit more modular.

At this stage, you've hopefully recalled how to build an expandable file uploading application with PHP 5 that uses only one custom function to transfer a target file from a client machine to a predefined web server. However, in the beginning, I said that I was going to teach you how to develop a brand new file uploading application using an object-oriented approach.

The finish off the FileUploader class they were working on previously and show some testing examples of it in action.