While Symfony2 is very flexible in terms of directory structure, it is recommended to keep the basic structure mentioned earlier.
So, in most cases, you will be usually modifying and creating the PHP files within the src/
directory, the view and configuration files within the app/
directory, and the JS/CSS files within the web/
directory.
Within the Symfony2 application, you will be using the "bundle" term quite often. Bundle is something similar to plugins. So it can literally hold any code controllers, views, models, and services. A bundle can integrate other non-Symfony2 libraries and hold some JavaScript/CSS code as well. We can say that almost everything is a bundle in Symfony2; even some of the core framework features together form a bundle. A bundle usually implements a single feature or functionality. The code you are writing when you write a Symfony2 application is also a bundle.
There are two types of bundles. The first kind of bundle is the one you write within the application, which is project-specific and not reusable. For this purpose, there is a special bundle called AppBundle created for you when you install the Symfony2 project.
Also, there are reusable bundles that are shared across the various projects either written by you, your team, or provided by a third-party vendors. Your own bundles are usually stored within the src/
directory, while the third-party bundles sit within the vendor/
directory.
The vendor directory is used to store third-party libraries and is managed by the composer. As such, it should never be modified by you.
There are many reusable open source bundles, which help you to implement various features within the application. You can find many of them to help you with User Management, writing RESTful APIs, making better documentation, connecting to Facebook and AWS, and even generating a whole admin panel. There are tons of bundles, and everyday brings new ones.
Note
If you want to explore open source bundles, and want to look around what's available, I recommend you to start with the http://knpbundles.com/ website.
The bundle name is correlated with the PHP namespace. As such, it needs to follow some technical rules, and it needs to end with the Bundle
suffix. A few examples of correct names are AppBundle
and AcmeDemoBundle
, CompanyBlogBundle
or CompanySocialForumBundle
, and so on.
Symfony2 is built based on components, and it would be very difficult to manage the dependencies between them and the framework without a dependency manager. To make installing and managing these components easier, Symfony2 uses a manager called composer.
You can get it from the https://getcomposer.org/ website. The composer makes it easy to install and check all dependencies, download them, and integrate them to your work. If you want to find additional packages that can be installed with the composer, you should visit https://packagist.org/. This site is the main composer repository, and contains information about most of the packages that are installable with the composer.
To install the composer, go to https://getcomposer.org/download/ and see the download instruction. The download instruction should be similar to the following:
If the download was successful, you should see the composer.phar
file in your directory. Move this to the project location in the same place where you have the composer.json
and composer.lock
files. You can also install it globally, if you prefer to, with these two commands:
You will usually need to use only three composer commands: require
, install
, and update
.
The require
command is executed when you need to add a new dependency. The install
command is used to install the package. The update
command is used when you need to fetch the latest version of your dependencies as specified within the JSON file.
The difference between install and update is subtle, but very important. If you are executing the update
command, your composer.lock
file gets updated with the version of the code you just fetched and downloaded. The install
command uses the information stored in the composer.lock
file and the fetch version stored in this file.
When to use install? For example, if you deploy the code to the server, you should use install
rather than update
, as it will deploy the version of the code stored in composer.lock
, rather than download the latest version (which may be untested by you). Also, if you work in a team and you just got an update through Git, you should use install
to fetch the vendor code updated by other developers.
You should use the update
command if you want to check whether there is an updated version of the package you have installed, that is, whether a new minor version of Symfony2 will be released, then the update
command will fetch everything.
As an example, let's install one extra package for user management called FOSUserBundle
(FOS is a shortcut of Friends of Symfony). We will only install it here; we will not configure it. We will configure it in the chapter focused on security and user management.
To install FOSUserBundle
, we need to know the correct package name and version. The easiest way is to look in the packagist site at https://packagist.org/ and search for the package there. If you type fosuserbundle
, the search should return a package called friendsofsymfony/user-bundle
as one of the top results. The download counts visible on the right-hand side might be also helpful in determining how popular the bundle is.
If you click on this, you will end up on the page with the detailed information about that bundle, such as homepage, versions, and requirements of the package.
Type the following command:
Which version of the package you choose is up to you. If you are interested in package versioning standards, see the composer website at https://getcomposer.org/doc/01-basic-usage.md#package-versions to get more information on it.
The composer holds all the configurable information about dependencies and where to install them in a special JSON file called composer.json
. Let's take a look at this:
The most important section is the one with the require
key. It holds all the information about the packages we want to use within the project. The key scripts contain a set of instructions to run post-install and post-update. The extra
key in this case contains some settings specific to the Symfony2 framework. Note that one of the values in here points out to the parameter.yml
file. This file is the main file holding the custom machine-specific parameters. The meaning of the other keys is rather obvious.
If you look into the vendor/
directory, you will notice that our package has been installed in the vendor/friendsofsymfony/user-bundle
directory.