By the end of this lesson, you’ll undertand how Symfony projects are organised. Along the way, we’ll be:
- Discussing Symfony Project layout
- Highlighting the paths that you should pay attention to as a beginner
If you have the GIT repository checked out and want to see the end result of this tutorial, it is the branch named master
To get started, open up your code editor (which is Atom if you are following this tutorial from scratch) and from the file drop down menu, click add project and use our web root as the destination. Taking a look at the file layout
|app||Configuration, templating, translations|
|bin||Some ready made binary utilities|
|src||Where we place any PHP code we create|
|tests||PHPUnit automatic testing schema|
|var||Auto generated code|
|vendor||Where any third party code downloaded by composer goes, including Symfony itself|
|web||The publicly accessable root of the project|
|composer.json||Schema for third party dependencies|
|composer.lock||The “current version” schema for use when running composer install|
|phpunit.xml.dist||A base configuration file to run with PHPUnit|
|README.md||A markdown file used to describe the project|
Pay special attention to
During your typical Symfony project, you won't have the need to touch all of the paths listed above. The majority of the work will be carried out in the following:
Any logic (PHP code) that you write will be located within this directory in the form of bundles. Bundles are a simply a structured way of defining functionality which Symfony can recognise.
When using the Symfony project builder, it will generate an AppBundle with a simple controller for you to build out from but, it is also the place where you will define data models and services.
This directory contains the Symfony kernel definition and configuration files which are used to determine how your app launches.
At the heart of Symfony (for web apps) is the kernel (as defined in AppKernel.php) which provides a structured workflow for handling requests, delivering responses and providing an interface which you plug code and functionality in to. When integrating extra bundles in to your project, they will be hooked in to Symfony by registering here
Configuration definitions that control how the framework will behave and information such as Database credentials are stored in the config directory.
The Resources/views directory is where you will store the templates for frontend presentation. Templates can be stored within bundles but, unless you are creating code that will be shared across projects, the app/Resources/views path is the officially recommended place to store them.
Composer is a dependency management tool which is responsible for the downloading / updating of third party code (including Symfony itself) and providing an autoloader to make it available throughout the app.
The composer.json file acts as a schema for this tool by defining a set of required packages that should be present within the environment.