Symfony 1.3 Web Application Development

Symfony Web Application. Development. Back in the days, PHP developers developed web sites using a mixture of PHP functional code and HTML, with no.
Table of contents

Preview — Symfony 1. This book is an example driven tutorial that takes you through the process of building Model-View-Controller-based web applications. You will create and develop an online store application. It also covers best practices for better and quicker application development.

This book is for PHP web developers who want to get started with Symfony 1. If you are already using Symfo This book is an example driven tutorial that takes you through the process of building Model-View-Controller-based web applications. If you are already using Symfony 1. Paperback , pages. Published September 24th by Packt Publishing first published September 1st To see what your friends thought of this book, please sign up. To ask other readers questions about Symfony 1. Be the first to ask a question about Symfony 1. Lists with This Book. This book is not yet featured on Listopia.

Alexandr rated it really liked it Oct 08, Cindarr added it Oct 26, Mulia Nasution added it Jun 09, Michel Lefranc added it Jun 24, Ben added it Aug 31, Each configuration file is related to a particular feature, and the next chapters will detail their use one by one. When you focus on a single file, you can see clearly what it does and how it is organized. For professional web development, the default configuration is often not completely adapted.

The configuration files allow for an easy modification of the symfony mechanisms without code. Imagine the amount of PHP code necessary to achieve the same amount of control. If all the configuration were located in one file, not only would the file be completely unreadable, but you could not redefine configuration at several levels see the "Configuration Cascade" section later in this chapter.

Symfony 1.3 Web Application Development

The configuration system is one of the great strengths of symfony, because it makes symfony usable for almost every kind of web application, and not only for the ones for which the framework was originally designed. During the course of application development, you will probably need to keep several sets of configuration in parallel.

For instance, you will need to have the connection settings for your tests database available during development, and the ones for your real data available for production. To answer the need of concurrent configurations, symfony offers different environments. An application can run in various environments. The different environments share the same PHP code apart from the front controller , but can have completely different configurations.

For each application, symfony provides three default environments: You're also free to add as many custom environments as you wish. So basically, environments and configuration are synonyms. For instance, a test environment will log alerts and errors, while a prod environment will only log errors.

Cache acceleration is often deactivated in the dev environment, but activated in the test and prod environments. The dev and test environments may need test data, stored in a database distinct from the one used in the production environment.

Symfony Web Application Development | Now just $10

So the database configuration will be different between the two environments. All environments can live together on the same machine, although a production server generally contains only the prod environment. In the dev environment, the logging and debugging settings are all enabled, since maintenance is more important than performance. On the contrary, the prod environment has settings optimized for performance by default, so the production configuration turns off many features. A good rule of thumb is to navigate in the development environment until you are satisfied with the feature you are working on, and then switch to the production environment to check its speed.

Symfony 1.3 Documentation

The test environment differs from the dev and prod environment in other ways. You interact with this environment solely through the command line for the purpose of functional testing and batch scripting. Consequently, the test environment is close to the production one, but it is not accessed through a web browser. It simulates the use of cookies and other HTTP specific components. To change the environment in which you're browsing your application, just change the front controller. Until now, you have seen only the development environment, since the URLs used in the example called the development front controller:.

However, if you want to see how the application reacts in production, call the production front controller instead:. They define the production front controller as the default execution script and allow for URLs like this:.


  • Symfony Documentation (Symfony Blog).
  • Friends and Others.
  • Any Time, Any Place.
  • Practical symfony.

Don't mix up the notions of environment and server. In symfony, different environments are different configurations, and correspond to a front controller the script that executes the request. Different servers correspond to different domain names in the URL. Usually, developers work on applications in a development server, disconnected from the Internet and where all the server and PHP configuration can be changed at will.

When the time comes for releasing the application to production, the application files are transferred to the production server and made accessible to the end users. This means that many environments are available on each server. For instance, you can run in the production environment even on your development server. However, most of the time, only the production environment should be accessible in the production server, to avoid public visibility of server configuration and security risks.

To prevent accidental exposure of the non-production controllers on the production system, symfony adds a basic IP check to these front controllers, which will allow access only from localhost. To add a new environment, you don't need to create a directory or to use the symfony CLI. Simply create a new front controller and change the environment name definition in it.

See a Problem?

This environment inherits all the default configuration plus the settings that are common to all environments. The next chapter will show you how to do this. The same setting can be defined more than once, in different places. The configuration system knows that a setting defined at the module level must override a setting defined at the application level. Of all the properties that can be customized, many are environment-dependent. Consequently, many YAML configuration files are divided by environment, plus a tail section for all environments.

The result is that typical symfony configuration looks like Listing In addition, the framework itself defines default values in files that are not located in the project tree structure, but in the sfConfig:: The default configuration is set in these files as shown in Listing These settings are inherited by all applications. Listing - The Default Configuration, in sfConfig:: These default definitions are repeated in the project, application, and module configuration files as comments, as shown in Listing , so that you know that some parameters are defined by default and that they can be modified.

This means that a property can be defined several times, and the actual value results from a definition cascade.

A parameter definition in a named environment has precedence over the same parameter definition for all environments, which has precedence over a definition in the default configuration. A parameter definition at the module level has precedence over the same parameter definition at the application level, which has precedence over a definition at the project level. This can be wrapped up in the following priority list:. Parsing YAML and dealing with the configuration cascade at runtime represent a significant overhead for each request.

Symfony has a built-in configuration cache mechanism designed to speed up requests. The configuration files, whatever their format, are processed by some special classes, called handlers, that transform them into fast-processing PHP code. In the development environment, the handlers check the configuration for changes at each request, to promote interactivity. They parse the recently modified files so that you can see a change in a YAML file immediately.

But in the production environment, the processing occurs once during the first request, and then the processed PHP code is stored in the cache for subsequent requests. The performance is guaranteed, since every request in production will just execute some well-optimized PHP code. As a consequence, most of the time, the YAML files aren't even parsed by the framework, which relies on the configuration cache instead. However, in the development environment, symfony will systematically compare the dates of modification of the YAML files and the cached files, and reprocess only the ones that have changed since the previous request.

This presents a major advantage over many PHP frameworks, where configuration files are compiled at every request, even in production. Unlike Java, PHP doesn't share an execution context between requests. For other PHP frameworks, keeping the flexibility of XML configuration files requires a major performance hit to process all the configuration at every request.

This is not the case in symfony. Thanks to the cache system, the overhead caused by configuration is very low. There is an important consequence of this mechanism.


  1. ;
  2. ?
  3. .
  4. Book Description.
  5. ;
  6. Top Secrets for Building a Sales Team and Expanding Your Business (A Top Secrets Book)!
  7. ;

    8. If you change the configuration in the production environment, you need to force the reparsing of all the configuration files for your modification to be taken into account. All the configuration files are eventually transformed into PHP, and many of the settings they contain are automatically used by the framework, without further intervention.

    However, you sometimes need to access some of the settings defined in the configuration files from your code in actions, templates, custom classes, and so on. The settings defined in settings. You can access settings from within the application code through the sfConfig class. It is a registry for configuration parameters, with a simple getter class method, accessible from every part of the code:. The parameter name is the concatenation of several elements, separated by underscores, in this order:.

    The environment is not included, since your PHP code will have access only to the values defined for the environment in which it's executed. For instance, if you need to access the values defined in the app. So symfony configuration settings have all the advantages of PHP constants, but without the disadvantages, since the value can be changed. On that account, the settings. Listing is interpreted as shown in Listing Refer to Chapter 19 for the meanings of the settings found in the settings. Most of the settings related to the features of an application should be stored in the app.

    This file is environment-dependent and empty by default. Put in every setting that you want to be easily changed, and use the sfConfig class to access these settings from your code.

    A gentle Introduction to symfony

    Listing shows an example. Listing - Sample app. To know if the fake credit cards are accepted in the current environment, get the value of:. When you should require an PHP array directly beneath the all key you need to use a category header, otherwise symfony will make the values separately available as shown above.

    TIP Each time you are tempted to define a constant or a setting in one of your scripts, think about if it would be better located in the app. This is a very convenient place to store all application settings. When your need for custom parameters becomes hard to handle with the app.

    In that case, you can store the configuration in a new file, interpreted by a new configuration handler. Refer to Chapter 19 for more information about configuration handlers. There are a few last tricks to learn before writing your own YAML files. They will allow you to avoid configuration duplication and to deal with your own YAML formats. Some configuration settings rely on the value of other settings. To avoid setting the same value twice, symfony supports constants in YAML files. On encountering a setting name one that can be accessed by sfConfig:: See Listing for an example.


    • Book Details?
    • Symfony Web Application Development by Tim Bowler.
    • Digital CCTV: A Security Professionals Guide.
    • Hedda Gabler and Other Plays (Classics).
    • .

    The path parameter will take the value returned by sfConfig::