Loïc Chardonne has posted the latest part in his "Symfony Differently" series (part one is here) with a focus on bootstrapping the application and configuring the environment that it will live in.

Our goal in this post is to bootstrap an application to then create a search endpoint for items. We've decided to use Symfony for a single reason: our company Acme used it since the beginning and the API developers team has Symfony and PHP skills.

He walks through the steps you'll need to get the application up and running:

Creating a new Symfony Standard Edition project

Configuring Apache

Moving the tests to a different directory, including Composer updates

Creating scripts for builds, testing and deployment

With all this structure in place, the next part of the series will start in on the functionality of the search endpoint and returning the results.

In this tutorial, we’re going to build and run a simple CRUD application from scratch using Laravel 5.

The target audience for the tutorial are those completely new to the world of Laravel so they start at the beginning. He walks you through the creation of a new Laravel project and the database setup and configuration. He goes through the creation of "resourceful routing" and using the Laravel "artisan" command line tool to generate the matching controller. From there he talks about views and Blade templating followed by the creation and execution of the needed database migrations. The tutorial wraps up with a look at the model system included with Laravel and how they fit in with the Eloquent ORM.

Fred Muya has posted a guide to his site today showing you how to configure custom logging in your Laravel 5 application. He replaces the default logging methods with an injected Monolog instance.

I recently started working on a Laravel 5 project, and I’d like to share how I set up my custom file logging. I pooled the information below from several sources (acknowledged at the bottom of the article).

Modifying the Kernel.php file to update the constructor for the bootstrap (both HTTP and Console)

With these changes in place you can then use the normal "Log" handling Laravel provides and the magic will all happen behind the scenes. He includes two examples of this, one with a simple log string and another with something a bit more complex (and the resulting log output).

The SitePoint PHP blog has kicked off a new series of posts today with the first tutorial about building an application with OOP and the Slim framework. In this starting article they focus in on bootstrapping the application and introducing some of the basics behind MVC and OOP.

At a certain point of my development as a PHP programmer, I was building MVC applications by-the-book, without understanding the ins-and-outs. I did what I was told: fat model, thin controller. Don’t put logic in your views. What I didn’t understand was how to create a cohesive application structure that allowed me to express my business ideas as maintainable code, nor did I understand how to really separate my concerns into tight layers without leaking low-level logic into higher layers. I’d heard about SOLID principles, but applying them to a web app was a mystery. In this series, we’ll build a quiz application using these concepts. We’ll separate the application into layers, allowing us to substitute components: for example, it’ll be a breeze to switch from MongoDB to MySQL, or from a web interface to a command-line interface.

They start off with a bit about why "MVC is not enough" and how they'll be applying domain modeling as a part of the application. There's also a brief mention of the concept of a service layer and how it will fit into the overall structure. Then it's on to the code: getting Slim installed (via Composer) and starting in on the interface/service classes for the Quiz. They walk you through entity creation for the Quiz and Question instances and a mapper to tie them together.

One exciting feature coming in Laravel 5 is the new Elixir package. At its core it is a wrapper around gulp to make dealing with assets easier. For my first look at this new tool I decided a good use case would be to setup Bootstrap and get everything working just like you would in a real world scenario. If you are not familiar, bootstrap includes three main components. CSS, JavaScript, and custom fonts. So we need to account for all those in our setup.

They walk you through the Elixir installation process (via node) of Gulp and setting up dependencies via Laravel's included "package.json" definition. He then shows how to install bower (another package manager) and use that to install the Bootstrap files (SASS version). Finally they show how to bootstrap these into your application's workflow - the SASS imported from bower, the fonts/javascript pulled in by gulp and finally the Elixir setup to merge them all together.

Apigility is a Zend Framework 2 tool that provides a REST API management interface, which is very useful if you want to build an API. Apigility can directly connect with your database and offer a full REST API for your application, but in most cases you already have an application build with Zend Framework 1.x (ZF1). Let's assume you have incorporated a lot of business logic in this application so it would be a waste not to use it building a rich REST API.

He uses the gitmodules functionality to bring his entire ZF1 application into the Apigility app's structure (or, alternatively, Subversion). He shows how to use Composer to install the actual Zend Framework v1 copy and how to pull in other third-party libraries. He includes the code you'll need to use to create a "ZF2APP_PATH" constant to get to the application path of Zend Framework v2 instance. He then gets into the main part - the actual autoloading and bootstrapping of the ZF1 classes/services. He gives a brief introduction to working with Apigility to make a new service and shows the update to the resource class.

On the SitePoint PHP blog today Taylor Ren has started up a new series about building web applications with the Symfony 2 framework. In this first post he looks at one of the initial steps - bootstrapping (setting up) the framework and application.

In this series, I will capture a few key steps and some advanced techniques (image manipulation, pagination, dynamic contents, NativeQuery, etc) to help anyone who is considering using Symfony (note, to avoid future confusion, Symfony here refers to the Symfony 2, not the obsolete Symfony 1) as their PHP framework to develop a website.

This first part helps you get everything all set up - the latest version of the framework, Composer and checking for the default page to make sure everything's configured correctly. From there he starts to get into the "guts" of the application, introducing the MVC elements (entities), routing concepts and database configuration/integration.

Rob Allen has a quick new post with details about configuring a view helper for a Zend Framework 2 application prior to its results being rendered.

When I was reading the documentation for the currencyFormat view helper, I discovered that you could configure the currency code and locale once rather than in every call. [...] This is obviously useful, but even more useful would be if we could set it once by default and then override if we need to in a specific call. The easiest way to do this is to use an event listener on the renderer.post View event within a modules's onBootstrap method.

He includes code to illustrate the process, configuring the renderer in the bootstrap of the application to use the GBP currency code and the "en_GB" locale for formatting its output. You can find out more about what the currencyFormatter can do in Rob's previous post.

PHP introduced a handy built-in web server that makes it much simpler to test applications quickly and locally than having to have a full Apache+PHP install sitting on you machine. In this new post to the VG Tech blog, they take it one step further. They suggest that you can use it for testing too.

As of PHP-5.4.0 the CLI SAPI provides a built-in web server. The web server is designed for development purposes, and serves requests sequentially. This web server can come in really handy when the need for an httpd arises during (integration) tests. In this post I’ll use PHPUnit as the testing framework, and I’ll show you how to start the web server during the bootstrap process, and how to shut it down when the test suite is finished.

His example shows the creation of a basic phpunit.xml configuration file, but the bootstrap is a little different than some you've seen. With the help of a few constants and a command-line call to start the web server, he gets things up and running and ready for testing. A shutdown command is also included as a registered shutdown function to clean up after the testing is done.

Fabien Potencier has posted the second part of his "packing a Symfony app in one file" series with this look at the bootstrapping of the application. You can find the start of the series (including his intentions) in part one.

The most common way to create a Symfony project is to start with the Symfony Standard Edition: it defines a sensible directory structure for your project and it make things a lot easier when someone want to take over an existing project as he knows where the templates, the controllers, or the configuration are stored.

This part of the series looks at some of the configurations and settings you'll need to get the application up and working in a minimal way. This includes moving everything into one YAML configuration file including routing information. He shows how some bundles, bootstrap code and things to remove from the composer config.