Category Archives: Symfony

Doctrine: Magic Finders

Doctrine offers some magic finders for your Doctrine models that allow you to find a record by any column that is present in the model. This is helpful for simply finding a user by their username, or finding a group by the name of it. Normally this would require writing a Doctrine_Query instance and storing this somewhere so it can be reused. That is no longer needed for simple situations like that.

The basic pattern for the finder methods are as follows: findBy%s($value) or findOneBy%s($value). The %s can be a column name or a relation alias. If you give a column name you must give the value you are looking for. If you specify a relationship alias, you can either pass an instance of the relation class to find, or give the actual primary key value.

First lets retrieve the UserTable instance to work with:

// test.php
// …
$userTable = Doctrine_Core::getTable(‘User’);
Now we can easily find a User record by its primary key by using the find() method:

// test.php

// …
$user = $userTable->find(1);
Now if you want to find a single user by their username you can use the following magic finder:

// test.php

// …
$user = $userTable->findOneByUsername(‘jonwage’);
You can also easily find records by using the relationships between records. Because User has many Phonenumbers we can find those Phonenumbers by passing the findBy**() method a User instance: Continue reading

Posted in Doctrine, ORM, Symfony, Technology | Tagged , , | View Comments

Doctrine ORM : Transitive Persistence

Transitive Persistence

Doctrine offers both database and application level cascading operations. This section will explain in detail how to setup both application and database level cascades.

Application-Level Cascades

Since it can be quite cumbersome to save and delete individual objects, especially if you deal with an object graph, Doctrine provides application-level cascading of operations.

Save Cascades

You may already have noticed that save() operations are already cascaded to associated objects by default.

Delete Cascades

Doctrine provides a second application-level cascade style: delete. Unlike the save() cascade, the delete cascade needs to be turned on explicitly as can be seen in the following code snippet:

// models/User.php

class User extends BaseUser
{
// …

public function setUp()
{
parent::setup();

// …

$this->hasMany(‘Address as Addresses’, array(
‘local’ => ‘id’,
‘foreign’ => ‘user_id’,
‘cascade’ => array(‘delete’)
)
);
}
}
Here is the same example in YAML format. You can read more about YAML in the YAML Schema Files chapter:


# schema.yml

# …
User:
# …
relations:
# …
Addresses:
class: Address
local: id
foreign: user_id
cascade: [delete]
The cascade option is used to specify the operations that are cascaded to the related objects on the application-level.

lease note that the only currently supported value is delete, more options will be added in future releases of Doctrine.

In the example above, Doctrine would cascade the deletion of a User to it’s associated Addresses. The following describes the generic procedure when you delete a record through $record->delete():

1. Doctrine looks at the relations to see if there are any deletion cascades it needs to apply. If there are no deletion cascades, go to 3).

2. For each relation that has a delete cascade specified, Doctrine verifies that the objects that are the target of the cascade are loaded. That usually means that Doctrine fetches the related objects from the database if they’re not yet loaded.(Exception: many-valued associations are always re-fetched from the database, to make sure all objects are loaded). For each associated object, proceed with step 1).

3. Doctrine orders all deletions and executes them in the most efficient way, maintaining referential integrity.

From this description one thing should be instantly clear: Application-level cascades happen on the object-level, meaning operations are cascaded from one object to another and in order to do that the participating objects need to be available.

This has some important implications:

Application-level delete cascades don’t perform well on many-valued associations when there are a lot of objects in the related collection (that is because they need to be fetched from the database, the actual deletion is pretty efficient).
Application-level delete cascades do not skip the object lifecycle as database-level cascades do (see next chapter). Therefore all registered event listeners and other callback methods are properly executed in an application-level cascade.
Database-Level Cascades

Some cascading operations can be done much more efficiently at the database level. The best example is the delete cascade.

Database-level delete cascades are generally preferrable over application-level delete cascades except:

Your database does not support database-level cascades (i.e. when using MySql with MYISAM tables).
You have listeners that listen on the object lifecycle and you want them to get invoked.
Database-level delete cascades are applied on the foreign key constraint. Therefore they’re specified on that side of the relation that owns the foreign key. Picking up the example from above, the definition of a database-level cascade would look as follows:

// models/Address.php

class Address extends Doctrine_Record
{
public function setTableDefinition()
{
$this->hasColumn(‘user_id’, ‘integer’);
$this->hasColumn(‘address’, ‘string’, 255);
$this->hasColumn(‘country’, ‘string’, 255);
$this->hasColumn(‘city’, ‘string’, 255);
$this->hasColumn(‘state’, ‘string’, 2);
$this->hasColumn(‘postal_code’, ‘string’, 25);
}

public function setUp()
{
$this->hasOne(‘User’, array(
‘local’ => ‘user_id’,
‘foreign’ => ‘id’,
‘onDelete’ => ‘CASCADE’
)
);
}
}
Here is the same example in YAML format. You can read more about YAML in the YAML Schema Files chapter:


# schema.yml

# …
Address:
columns:
user_id: integer
address: string(255)
country: string(255)
city: string(255)
state: string(2)
postal_code: string(25)
relations:
User:
local: user_id
foreign: id
onDelete: CASCADE
The onDelete option is translated to proper DDL/DML statements when Doctrine creates your tables.

Note that ‘onDelete’ => ‘CASCADE’ is specified on the Address class, since the Address owns the foreign key (user_id) and database-level cascades are applied on the foreign key.

Currently, the only two supported database-level cascade styles are for onDelete and onUpdate. Both are specified on the side that owns the foreign key and applied to your database schema when Doctrine creates your tables. Continue reading

Posted in Doctrine, ORM, Symfony, Technology | Tagged , , | View Comments

Symfony Exceptions

In case of error or unauthorized access to, for example, it makes sense to throw an exception. In order to react to the error conditions better, should throw it back on the correct type of the exception and not always … Continue reading

Posted in Symfony | Tagged , | View Comments

symfony form field without a label

I was standing in front of the problem that I have a form with only one field. In this case the label of the field has shown no sense. For this reason, it had gone – but how? The solution … Continue reading

Posted in Symfony, Technology | Tagged , , | View Comments

Symfony2 WebProfiler

Symfony2 just introduced its WebProfiler, the utility will soon be the favorite of all programmers. Most veterans will recall that five years ago was the first Symfony framework to include a web debug toolbar. This bar displays useful information for debugging applications and provides access to all logs with a single click:

Symfony2 presents its WebProfiler as the great evolution of the web debug toolbar. Whenever you view a page, Symfony2 generates a unique token debug (pictured above, the token is 4c7e59811509c). By clicking on that token, it shows the WebProfiler with all the debug information:

In the menu on the left side you can see the five main sections to the Profiler which now has:

Request: displays information about the request and response (parameters, cookies, headers).
Exception: if the request has caused an exception, it shows the type of exception, the message from the server and the whole execution trace.
Events: Shows the events raised during execution of the application (along with their event listeners) and the events that have been identified but have not come to run.
Logs: Displays the same information to log the original debug toolbar.
Doctrine / Propel: shows the queries to the database and the time taken for each.
Another great features of the Profiler is that it keeps all your information in a database called SQLiteprofiler.db and stored in the directory cache/ in your application. With this database, you’ll be able to consult the entire execution history of your application, which will facilitate the clearance of projects:

If you want to try the Profiler, you need version of the sandbox Symfony2 PR3, which has not yet been published as a downloadable file. Therefore, when you can only download via git:

mkdir sandbox
git clone http://github.com/symfony/symfony-sandbox.git sandbox
cd sandbox /
git checkout PR3
Now you can try accessing http://localhost/sandbox/index_dev.php Continue reading

Posted in Symfony, Technology | Tagged , , , | View Comments

Multiple domains on symfony project

This post is about developing a symfony project that provides multiple applications that are reachable on multiple top level domains. In our case, the symfony applications “UMTS Netzabdeckung” and “Flatrates Vergleich” share the same backend (models, data, etc.) but each site is a standalone application and has a dedicated top level domain.

Create two applications

The first step is to create two applications. Run

symfony generate:app site1
symfony generate:app site2

in your console and change the default actions, routing, etc. Same thing as usual.

Edit .htaccess

The next step is quite simple: Open your .htaccess file in /sf_project_dir/web and insert your second application to the .htaccess file (BEFORE the default RewriteRule)

RewriteCond %{HTTP_HOST} secondhost.com$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ site2.php [QSA,L]

That’s all!

That’s all to get it working. Each request to your second domain will be redirected to the according application. A drawback is, that your “frontend” application is still reachable on your second domain if you type in the script name directly. Since I’m not an htaccess expert, I just added some php code to my index.php:

if($_SERVER['SERVER_NAME'] != ‘www.flatratesvergleich.de’) {
header(‘Location: http://www.flatratesvergleich.de’ . $_SERVER['REQUEST_URI']);
die;
} Continue reading

Posted in General, Symfony | Tagged , , , , | View Comments

Symfony without a slash at the tail

Most-frequently asked question in the channel for symfony:

  1. how to get rid of the slash on the end of the URL DoctrineRouteCollection
  2. why not take the last slash
  3. etc. in the same vein

So you just a snippet of advice:

# To avoid trailing slash problem RewriteRule
^(.+)/$ http://% (HTTP_HOST) / $ 1 [R = 301, L]

Scientific value of the snippet does not represent, but the question really often ask) so that “search and ye shall find”))

Have fun! Continue reading

Posted in Symfony | View Comments

Snippet: Symfony & Propel–Queries with SQL functions

This is a super short snippet that I ALWAYS forget how to do! Often I want to build more complex where clauses with Propel Criteria which use SQL functions such as UCASE, LCASE, LEN and the date functions DAY, MONTH and YEAR. This is possible using Propel & Criteria, but how to do it is not immediately obvious.

The snippet below shows how to select objects from the database which were created in a specific month and year. Using Criteria::CUSTOM, it’s possible to specify a column and a comparison to do with that column. This is quite useful for doing things like building archive lists.

$c->add(MyObjPeer::CREATED_AT, ‘MONTH(‘.MyObjPeer::CREATED_AT.’)=’. $month, Criteria::CUSTOM);
$c->addAnd(MyObjPeer::CREATED_AT, ‘YEAR(‘.MyObjPeer::CREATED_AT.’)=’. $year, Criteria::CUSTOM);
A Note on Snippets: When using frameworks such as Symfony it is often the simplest pieces of code which are the hardest to either find or remember. These snippets are placed here for my own reference and will hopefully be useful to others. If you find them useful or have any suggestions, please let me know. Continue reading

Posted in Symfony | Tagged , , , | View Comments

Using Namespaces in Propel 1.5

Propel 1.5 does not cease to please the pace of development and introduction of new features, just a few weeks ago, Francois Zaninotto(project leader Propel) has published a new opportunity to edit the nested forms using mergeRelation and embedRelation and the other day to use Namespaces in the generation of models.

Propel 1.5 allows the use of Namespaces in files describing your model if you are using in the php version 5.3

Add the use of models is very simple:






A model class:

/ / Use fully qualified name
$ Book = new \ Bookstore \ Book ();
/ / Or use an alias
use Bookstore \ Book;
$ Book = new Book ();
/ / Remember to use the \ namespace for core Propel classes in this case
$ Con = \ Propel:: getConnection ();
$ Book-> save ($ con);
More details can be read in the blog Francois Zaninotto Continue reading

Posted in Symfony | Tagged , , , , , | View Comments

Symfony Coding Standards

Following coding standards is one of the easiest way for everybody to understand everybody’s code.Here’s the golden rule: Imitate the existing symfony code. Never use tabulations in the code. Indentation is done by steps of 2 spaces: <?php class sfFoo … Continue reading

Posted in Symfony, Technology | Tagged , , , | View Comments
Get Adobe Flash playerPlugin by wpburn.com wordpress themes

DecentMind is Digg proof thanks to caching by WP Super Cache