With the release of symfony 1.0, it’s time for those who haven’t tried it yet to see what’s inside this beautiful framework. Stable, fully documented, and released under the open-source MIT license, symfony is used by hundreds of web sites, including some very large ones (Yahoo! Bookmarks, with its 20 million-strong user base, is built with symfony). If you haven’t taken the time to look at the introductory screencasts on the symfony project website, this simple tutorial will lead you through the basics.
The best way to learn and understand symfony is to use it, so this article will lead you through the creation of a photo album application with this framework. You already know the basic features such an application should offer: the ability to upload photos, to describe and tag them, and the ability for visitors to browse and comment on your photos.
Symfony is a Model-View-Controller (MVC) framework written in PHP that’s aimed at building web applications. If you’re already familiar with the MVC paradigm, you won’t be surprised by the way symfony organizes scripts. If you aren’t familiar with MVC, you just need to understand that separating the code into three parts — the logic code (called the Model), the presentation code (the View), and the request handling code (the Controller) — is a good way to ensure the maintainability and reusability of code.
Not only is Symfony an MVC implementation in PHP, it also integrates a lot of objects that facilitate the development of web applications — and integrates them all with a coherent syntax. Smart URLs, code generation, easy templating, internationalization, caching, automated form validation, and Ajax, are among the most appreciated symfony features. Developing an application with symfony is slightly different than building it with any other framework, or without any framework at all. It’s faster, more productive, and just plain fun. But enough talk, let’s see some code.
Initializing an Application
First, you need to get the symfony files. Fortunately, one of the distributions of the framework comes packaged with an empty application and an SQLite database already configured and working straight out of the box. A working web server with PHP5, and shell access, is all that symfony requires to work.
To install symfony, simply download the sf_sandbox.tgz file.
Unpack it under the web root of your server directory. You can check for yourself that the installation went smoothly by browsing to this URL (note that it may vary depending on your individual setup): http://localhost/sf_sandbox/web/frontend_dev.php.
The directory structure of this new project is quite easy to understand:
sf_sandbox/ // project directory
apps/ // application files
batch/ // batch process scripts
cache/ // cache files
config/ // configuration files
data/ // data files and scripts
doc/ // documentation files
lib/ // vendor libraries and general purpose scripts
log/ // log files
plugins/ // plugins
test/ // unit and functional tests
web/ // public web directory
Many of these directories are empty for a new application; this directory structure can be regarded as a guideline to organize the files of a project effectively. The good news is that as soon as you understand how this directory structure works, you’ll be able to understand any symfony project: they’re all structured in the same way.
In most situations, web applications store data in relational databases, so the data structure has to be described as a set of columns grouped in tables that are linked via foreign keys. For the photo album application, the data schema consists of three tables: photo, tag, and comment. To describe their columns and relationships, we use a simple format called YAML (pronounced “yamel”), which looks like this:
propel:
photo:
id: ~
file_path: varchar(50)
description: longvarchar
created_at: ~
tag:
photo_id: ~
name: varchar(50)
comment:
photo_id: ~
author: varchar(50)
body: varchar(50)
created_at: ~
YAML is an alternative to XML for representing data structures. The syntax is pretty simple: structure is shown through indentation, and key/value pairs are separated by colons. The first line represents the name of the database connection for this schema. Propel is the default name in this sandbox — it refers to the included SQLite database. Propel may sound like a strange name to use as a default, but in fact, the name comes from a third-party component that’s integrated into symfony.
In this schema, tildes (~) are used instead of the explicit declaration of a data type, because symfony can induce the data type from the name of the key. For instance, the id column of the photo table is most obviously a primary key, so its type should be integer, and it should be auto-incremented. The created_at name obviously refers to a date, so it should be typed as a timestamp. And the two photo_id columns look very much like foreign keys to the id column of the photo table.
Symfony knows YAML, and understands this schema exactly as we described it. Open the schema.yml file under the main config/ directory of the sf_sandbox directory (sf_sandbox/config/schema.yml), and place the above YAML code in that file. Symfony is now ready to generate the Object-Relational Mapping (ORM) for that schema.
What is Object-Relational Mapping? Well-designed web applications don’t access data directly using SQL; instead, they use objects to interact with the database. Symfony uses an internal code generator to create the objects that correspond to the photo, tag, and comment tables, based on the object-relational mapping defined in the schema.yml file. To generate those objects, you just need to call one command from the shell. And that’s our cue to meet the symfony command line interface (CLI)!
Here’s the symfony script that lies at the root of your project:
$ cd sf_sandbox
$ php symfony propel-build-all
The propel-build-all command (there’s that propel name again) generates the model classes under the lib/model/ directory (and creates the related tables in the SQLite database of the project). The classes are named Photo, Tag, and Comment, because symfony’s convention for class names is CamelCase. Like most classes in symfony, the model classes are autoloaded, which means that you can use them without manually “requiring” their files in the code (with include or require statements). Just remember to call the clear-cache symfony script each time you add a new class so that the symfony autoloading system can take it into account. Since you just created some classes, go ahead and call that script now:
$ php symfony clear-cache
We’ll get back to these classes later, but first let’s look at the photo publishing interface.
get from : http://www.sitepoint.com
