Delivering Quality

The symfony web framework provides two methods for building the database model files when using the Propel Object-relational mapping (ORM) toolkit. The recommended method by the symfony team is to use the schema.yml file, where you explicitly explain your table structure. The second method is to generate a schema.xml file directly from the database.

schema.yml:

Just edit config/schema.yml and list your tables, columns, column types, and foreign keys in YAML form. Build the model files by running:

./symfony propel-build-model

Pros:

• Interfaces better with plugins because most, if not all, plugins use the schema.yml method
• Can be used to create the database tables
• Overall easier to use because it is the most common method

Cons:

• Requires duplicate data by having the database structure in a text file, which can be outdated when the database is updated directly

schema.xml:

To create the model files simply run:

./symfony propel-build-schema xml
./symfony propel-build-model

Pros:

• Supports ALL  database features
• Supports the most complex schemas

Cons:

• Errors while building the XML file are cryptic and time consuming to track down (eg: om-template)

Comparison

The schema.yml method supports most projects with relative ease, but is limiting if you need to use more advanced database features that are not supported (propel only supports limited column types). Although, there are tricks to get around these limitations. For example, if you need to use column types that aren’t supported, like ENUM, you can simply declare the column as a varchar and Propel won’t know any better. This works fine for ENUM because it’s simply a text field, but may work for other column types too.

I recommend the schema.xml file for projects that have a very complex schema that cannot be represented in the yml file, or for projects already using XML files to define the database scheme.

I have used both methods on different large projects and have found the schema.yml method to provide faster  application development, have more developer support, and easier to work with. I full recommend use of the schema.yml method in all but the most exceptional projects.

Have you built a form while developing with the symfony form framework that appears to work fine but fails because of an unknown error?

The plain and simple easiest way to catch most errors  is to output the default form. The default form printed to the screen by echo $form; which will show you any validation errors that appear in the form but were missing on your customized version, or give you a hint as to what is wrong.

Your test form would look like this:

The symfony CRUD generator is a very useful tool for speeding up your web development. When you need a list of items that you can list and edit, you are most likely building a standard CRUD (create-read-update-delete) interface. This is common functionality that is found in most applications. Since this is such a common task, it makes perfect sense that the symfony web framework has a tool to build it for you.

For example: Lets say your web application allow users to sign-up (surprise!) and you need a user management tool in the admin section to manage these users. To create this in symfony, you'd run the following:

./symfony propel:generate-crud admin user User

This assumes you have an admin application, and a User model file. With that one line, it will create a listing of all users with the ability to edit and delete them. It generates HTML and PHP code that you can modify to your requirements. Fantastic for less than a minute of work!