Tag Archives: ORM

A symfony1.4 to Symfony2 migration: Why you should learn Symfony2

Posted on by
A symfony1.4 to Symfony2 migration: Why you should learn Symfony2

Since a few months all the PHP developer’s community is quite in turmoil about everything that’s going on. PHP 5.3 is becoming very standard, Zend is in heavy development for his new version and Symfony2 is on the point to release his final version.

What’s happening?

Before going further, I must make a quick overview of what’s happening in the world of PHP developers.
The news coming frameworks are reaching a new step in professionalization of PHP developments. And this one is very huge! The provision of modern design patterns such as SOC (separation of concerns), DI (Dependency Injection) or Annotations (even if it not really a design pattern) pulled the Frameworks to new high quality standards. Note that Java and Microsoft worlds joined this state years ago, PHP is just catching up.

And this catching up is really fast! Essentially thanks to GitHub which allows the lead development team to be easily helped by thousands of voluntary developers all around the world. Really, GitHub community amazes me every day.

Consequently, new generation PHP Frameworks relegate past frameworks to an old way of developing. “Yea my Framework does MVC! So don’t I have some kind of a modern architecture?” Of course not! I am quite bored of this excuse which leads to poor development quality. Take for example the Symfony1.4 Framework. It uses obviously MVC, but outside of the views and controllers all the rest stays messy.

What I realized last months is that PHP development became a language where you can really develop an expertise based on framework but also on architecture and best practices. And it feels right. You cannot tell anymore that you master PHP just because you understand the language and a Framework.

Fact: PHP is becoming a very professional and valuable technology, just next to Java and .NET.

PHP and some"modern" Frameworks

PHP and some"modern" Frameworks

Learn a new Framework

What I did in the beginning of 2011 is the migration a full featured website from symfony1.4 to Symfony2.

First of all, I must say that symfony1.4 is a tremendous Framework. It is reliable and well-conceived. I learned a lot using it. If you like it and are using it on current projects, you should definitely keep it.
But when I saw Symfony2 at the end of 2010, I couldn’t help myself but to be thrilled about it. Symfony1.4 is nice, but Symfony2 is so much better!

You have several advantages to learn and use Symfony2. You will learn and use new philosophies and best practices that are very valuable. Functionalities and performances are better. Team development is enforced with a much decoupled framework. And you can easily leverage the GitHub community which tests and improve the Framework every day or provided Bundles for every need.

You should learn Symfony2, but the road is not easy.

Symfony1.4 to Symfony2

Yes, the architecture is completely different. And despite the fact that the name stays the same, you will have to recode everything again. This is why we advise to keep current symfony1.4 project the way they are.

Of course, you will get some kind of a step by step tutorial to migrate the code. But at the end you will recode everything.

The general architecture

The main difference is that this time you won’t code into the framework (remember the model directory for example). You will have to create a Bundle.
A Bundle is some kind of a library that has the ability to be plugged into Symfony2. Bundles are very independent one from another and are at the core of your application. Note that Symfony2 is itself built on Bundles. Also, old plugins are now Bundles.

A Bundle could be your model, your frontend, a web service, a template engine, an ORM, a search engine, an integration of TinyMCE… so Bundle is a very large notion in the Symfony2 framework. The main interest it that they can be very easily plugged, updated and configured.

It took me several months to fully understand what the implications of using Bundles are. But once you’ll get it, you won’t want to leave it.
Also Symfony2 relies on the concept of dependency injection. It is very important to understand why it is build this way, what the container is and what it implies. When you’ll know how it works, the Framework will become very easier to understand.

Doctrine2

Doctrine2 works differently.

The first thing you’ll notice is that Doctrine does not rely on code generation. Now you will have to code your objects yourself. Hopefully the command can help you to build your first objects, but you should rapidly code your files directly.

Consequently, your objects are not using any base class. They are lighter but they don’t have any access to the ORM, and should not contain the saving logic anymore.
You might also use annotation, which are very powerful and have the merit to explicitly set relationships.
What I like with Doctrine2 is that your model is now very light and explicit. You won’t have the WTF effect any more when a relation or column is not loaded/stored correctly because of a wrong “schema.yml” file.

The Controllers

Controllers may contain the same kind of logic; the way they work is different. Now you have to consume services. And so you will learn the notion of services and begin to use one of the core items of the Symfony2 architecture: the container. No more static classes, you will rely on real instances that are parameterized via all the dependency injection and services logic.

Really, services, dependency injection and the container are very nice things. They allow your code to be more decoupled and more robust.

The views

Twig is one of the most powerful stuffs in Symfony2. You may don’t want to use it, but I strongly encourage you to do so.

The syntax is less verbose, and you can have a lot of nice functionalities. Auto escaping, easy access to variables, template inheritance, easy test structures (which can be boring in php, such as testing the existence of a value, or test even/odd occurrences in a loop), filters (truncate, text replacement, capitalization)… and so on.

Twig is a language dedicated to designers, so that you won’t have to teach them PHP.

Also Twig will impose you to have only view logic in your view. And that is great! You designer can concentrate on creating a nice interface without messing with your business logic.

The routing

Really, the routing looks like to be the least changed component. It became a little simpler than before, can be used with annotations and has some nice new functionalities such as the param converter.

Forms

Forms completely changed. It is a brand new form Framework which works like a mix of MVVM and Converter design patterns (very common in .NET). You will have to go through all your forms in terms of composition, validation, and process.

As far as I can see, the new Form framework is not so easy to master. It is also one of the last stable components in Symfony2. As long as I can see, when it comes to functionalities, there is no major improvement.

But when you get how to use them, they become very powerful and fast to use. Especially thanks to the validation that can use annotations, and the very clean process of form construction.

Security

The security component is certainly the hardest to master. The first time I had to use it, it was very painful. You will have to understand many new concepts, such as the provider, the firewalls, the encoders…
But you will have a very powerful tool to really control every aspect of your web application security and authorization mechanisms.

I18n

The translation of your views is very clean and perfectly integrated in the twig syntax. The forms won’t get you any trouble.

But there is no out of the box process for the translation of your doctrine object. You will have to install the doctrine extensions, which are kind of official and not very hard plug, in order to support this feature.

On the bright side you can now have your translations in xliff files, but also php, yaml, and more.

Extending the framework

This last point is certainly one of the most important. Because complete parts of the framework are Bundles, it is very easy to build new bundle and makes them do whatever you want! Also it allows you to override very easily the way the framework behaves.

Because Bundles are kind of standalone, you can share them and plug them very easily. You can already find very popular bundles with very powerful stuffs in it. I am thinking about the KnpUserBundle, the SonataAdminBundle, the StofExtensionBundle or the ImagineBundle.

What will happen?

The first thing you might want to do is to download the Symfony2 package, configure your web server, and see what comes out. But it is not so easy. You first have to choose a distribution, get the “vendors”, maybe by using git…

Just after that you will go through the doc, and see that you have so many things to read, with some kind of an arbitrary order. Also they are a lot of cookbooks that contains so many features to discover. You will just want to know everything in order to make the right decisions. But you will still want to code.

You will be overwhelmed by the Framework and feel kind of lost. Almost I did.

You will “loose” time reading doc, learning new ways of doing stuffs that were working perfectly on your last framework. You will be stuck again common issues, and some other tricky functionalities will work very smoothly. At last you will learn to watch Github regularly to follow the development of some bundles, read the doc hosted there, and so on. You might not want to do that at the beginning (it is not what you came for)… but you will do.

The truth is that your first Bundle (application) will be crappy. Sure it will work, but you’ll be frustrated to miss some new features along the way. So you might refactor several times before getting all the potential of Symfony2.

During my migration I did not just recode everything. I had to refactor my forms two times, my security and the import of the assets one time. My controllers were permanently recoded to follow these changes. And so on.

The same thing happened to me when I discovered Symfony1.4. But, as always, you will feel some kind of betrayed by the Framework. You will have to overcome many frustrations and disappointments. And it might last for some months, but you had the strength to learn symfony1.4 so the learning of Symfony2 will be incredibly fast!

After all you will be a kid again, playing with big toys. You will surely miss your old ones, miss some functionality. But when you will know how to use them, they will become very pleasant tools.

The change curve

The change curve

What you’ll miss

Symfony2 is not so extraordinarily good. It is still very young, and it is thus missing some functionalities that symfony1.4 has.

You can forget about the admin generator for the moment. Symfony2 should get one, but not now. You can still compensate by using the SonataAdminBundle or the WhiteOctoberAdminBundle.

The Framework is too much flexible at first. You can do almost any file architecture. You can use xml, yaml, php or annotation as configuration. It seems nice, but sometimes it is kind of confusing to have a permissive Framework, especially after using symfony1.4.

No Jobeet. No Jobeet. No Jobeet. Sadly it is not coming soon. I have seen some projects to migrate the Jobeet project to Symfony2, but it is not very conclusive yet.

The magic. You will have to code your assessors yourself (or use a helper command), you will have to explicitly route your controllers and templates…

What you’ll like

The performance! Nothing more to say.

The new debug toolbar which is more powerful.

The documentation. It has no Jobeet, but it becomes more complete every day and you won’t have a specific documentation for the 1.0 to 1.4/Doctrine/Propel versions of the Framework. It wasn’t the case a month ago, but now the Symlfony2 documentation is more complete that the Symfony1.4 one. Thanks to the documentation team and the Github contributors that do a tremendous work.

Everything is explicit. “No more magic” can look like a nice easy thing to say, but is a very apparent and useful. Now the templates are called because you wrote it, your assessors are explicitly written, logic is not hidden into base classes that belong or are generated by the Framework, your configuration is loaded because you referenced it… No more “finger crossed” effect.

The community. The Symfony community has never been so active. You have lot developers ready to help you whatever your problem is. Moreover your will find a lot of nice Bundles on Github provided by the community.

You will learn a lot! You will use valuable practices and standards. You will build powerful, robust and nice web applications. And finally you will become a better developer than ever.

Some extras

Of course Symfony2 comes with some killers features. Let’s talk about some of these.

The management of assets is incredibly neat. The pre-packaged AsseticBundle can handle in a very elegant way all your assets. They can be images, css or js. But it can also compile on the fly coffee script, sass, lesscss or more, minifies tem, combine them and cache them!

You can do more by using the ImagineBundle that will handle your images. It will generate thumbnails, apply filters or watermark on the fly depending on what you ask in your templates. And it is cached.

Yes, my designer is very happy!

The cache has never been so powerful. Symfony2 uses the http headers (what a weird nice idea) coupled with a reversed proxy to reduce drastically what your application need to compute. Also it integrates in an almost transparent way the handling of ESI cache (if you don’t know it, you should at least look at this: http://en.wikipedia.org/wiki/Edge_Side_Includes).

Functional and unit tests are completely integrated into phpunit so that you can leverage a true PHP unit test framework.

Because everything is decoupled in bundles and only accessed via the container, your classes are loaded just when you use them. And it results in a very lightweight Framework compared to what symfony1.4 was.

The management of updates. It was not so easy at the beginning, but the core development team came with a script that can update your entire framework and dependency bundle just by reading a “deps.ini” file. Because your code is in a completely isolated Bundle you won’t have to do more than update the “deps.ini” file and run a simple command (which wasn’t really the case with symfony1.4 where your code were placed everywhere in the Framework).

What did I get?

I already told some of the reason why you should learn Symfony2. But there is more to say.

Again, Symfony2 will teach you many new nice things. You will learn. You will be a better developer than ever. And you will be more valuable.

Also your application will become much more powerful, fast and reliable. And that not nothing! I never felt so confident about my development and my websites.

At last you might enjoy it! Many new features of Symfony2 allow you to do so powerful stuffs without all the boring code. I am thinking about ESI, Assets management, Twig, Annotations, Bundles…

At the beginning you will hate learning Symfony2, but at last you won’t regret it.

Slides about .NET, Linq, Entity Framework, Windows Phone 7

Posted on by
Slides about .NET, Linq, Entity Framework, Windows Phone 7

I just uploaded some slides I made for the preparation of a scholarship project. I made a quick overview of .NET, C#, Linq, Entity Framework, Windows Phone 7… for people who already have experienced Java and/or C++.
It’s in French. Feel free to react and to post me your comments.

Je viens juste d’uploader des slides que j’ai faits pour la préparation d’un projet scolaire. J’y fait un rapide aperçu de .NET, C#, Linq, Entity Framework, Windows Phone 7… pour les personnes ayant déjà une expérience en Java et/ou C++.
N’hésitez pas à réagir et à poster vos commentaires.

How to use filters on custom fields with symfony 1.4

Posted on by
How to use filters on custom fields with symfony 1.4

I recently continued to use my particular relationship that embeds some properties. This time I wanted to add some filters to my student request using the pre-generated filter used in the backend.

Here again, is our example:

N to N relationship with properties

N to N relationship with properties

And the pre-coded filter is here:
[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
public function configure()
{
}
}
[/php]

Here the filter already includes fields for every field on Student objects (id and name). It is a regular form, so you can override the predefined widgets and validator or even unset some of them. Let’s unset the id:

[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
public function configure(){
unset($this['id']);
}
}
[/php]

Now we can use our filter like this in our controller:
[php]
// app/frontend/module/student/actions/actions.class.php
class studentActions extends sfActions {
public function executeIndex(sfWebRequest $request) {
//create a default query
$query = Doctrine::getTable(‘Student’)->getQuery();

//obtain the filter values that could have been submited
$filterValues = $request->getParameter(‘student_filters’);
//create the StudentFormFilter using the values, and giving it the query
$this->formFilter = new StudentFormFilter($filterValues);
$this->formFilter->setQuery($query);
//if the form have been submited
if($filterValues){
//bind the values
$this->formFilter->bind($filterValues);
//if valid, specialise the request using the form
if($this->formFilter->isValid())
$query = $this->formFilter->getQuery();
}

//finally get the students
$this->students = $query->execute();
}
}
[/php]

This code could seem a little weird but it is finally all you need to know in order to make a basic use of the auto generated filters. Thus, your template can look like this:

[php]
<?php echo form_tag(url_for(‘student_index’)) ; ?>
<table>
<?php echo $formFilter ; ?>
</table>
<input type="submit"/>
<?php echo ‘</form>’ ?>
// …
<ul>
<?php foreach($students as $student): ?>
<li><?php echo $student->getName(); ?></li>
<?php endforeach; ?>
</ul>
[/php]

Ok, everything is working quite well. But, let’s getting our filter trickier. I want to add a filter that permits me to select students that have a specific enrolment date.

First of all, we need to add a widget and a validator:
[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
public function configure()
unset($this['id']);

$this->setWidget(‘EnrolmentDate’, new sfWidgetFormFilterDate( array(
‘from_date’ => new sfWidgetFormDate(),
‘to_date’ => new sfWidgetFormDate(),
‘with_empty’ => false)));
$this->setValidator(‘EnrolmentDate’, new sfValidatorDateRange(array(
‘required’ => false,
‘from_date’ => new sfValidatorDateTime(array(
‘required’ => false,
‘datetime_output’ => ‘Y-m-d 00:00:00′)
),
‘to_date’ => new sfValidatorDateTime(array(
‘required’ => false,
‘datetime_output’ => ‘Y-m-d 23:59:59′)))));
}
}
[/php]

Here, our form will display properly, but the getQuery method used in the will simply ignore our new EnrolmentDate field.

Now the things are getting really uncommon. Symfony is not really built for this kind of behavior, and we will need to override some behavior in our StudentFormFilter to get thing to work. In order to do that I read the sfFormFilterDOctrine.class.php file and more specifically the doBuildQuery function where the request is built. Some of the things I’ll do are a bit ugly but it is the price to pay if we want not to spread our modifications into the core framework, thus I managed to keep everything in the StudentFormFilter.class.php file. This way our ugliness remains contained into a single file and does not impact the framework. So let’s go for it!

First of all we need to add the EnrolmentDate as a new field of the form, to do that we need to override the getFields function:
[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
// …

public function getFields() {
return array_merge(parrent::getFields(), array(‘EnrolmentDate’=>’EnrolmentDate’));
}
}
[/php]

The very important thing here is to know that I added a field EnrolmentDate of type EnrolmentDate. It will be crucial later.

Also, the doBuildQuery method will get the Student table and check for the presence of the field EnrolmentDate. The workaround here is to make a stub table and override the getTable function in order to return this stub table.

[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
// …

public function getTable() {
return new StudentStubTable();
}
}

// my stub table
class StudentStubTable extends StudentTable{
public function hasField($field) {
if($field == ‘EnrolmentDate’)
return true;
else
return parent::hasField($field);
}
public function getFieldName($field){
if($field == ‘EnrolmentDate’)
return ‘EnrolmentDate’;
else
return parent::getFieldName($field);
}
}
[/php]

As you can see, two methods need to be overridden in my StudentStubTable class. Those two functions are used by the doBuildQuery function. Here i make the field EnrolmentDate exist and create his fieldName in the table is EnrolmentDate.

From here, all we need to know is that the doBuildQuery function will look for an addEnrolmentDateQuery function in our StudentFormFilter class. This function is called based on the type of the fields that I defined earlier in the getFields method. This call is made by the concatenation of ‘add’ + type of the field + ‘Query’.

So, let’s code the function and make it do our join with the Enrolment table.

[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
// …

public function addEnrolmentDateQuery(Doctrine_Query $query, $field, $values) {
//add our join part
$query->leftJoin(sprintf(‘%s.Enrolment enrolment’,$query->getRootAlias()));

//set the where part depending on the value
if (isset($values['is_empty']) && $values['is_empty'])
{
$query->addWhere(‘enrolment.EnrolmentDate IS NULL’);
}
else
{
if (null !== $values['from'] && null !== $values['to'])
{
$query->andWhere(‘enrolment.EnrolmentDate >= ?’, $values['from']);
$query->andWhere(‘enrolment.EnrolmentDate <= ?’, $values['to']);
}
else if (null !== $values['from'])
{
$query->andWhere(‘enrolment.EnrolmentDate >= ?’, $values['from']);
}
else if (null !== $values['to'])
{
$query->andWhere(‘enrolment.EnrolmentDate <= ?’, $values['to']);
}
}
}
}
[/php]

In this method, we retrieve the query as a parameter and we just have to build our method based on the values we receive. Everything here is about building a proper DQL query.

Now we have a nice filter that can filter on our property embedded into a relationship.

Here is the final code:

[php]
// lib/filter/doctrine/StudentFormFilter.class.php
class StudentFormFilter extends BaseStudentFormFilter
{
public function configure()
unset($this['id']);

$this->setWidget(‘EnrolmentDate’, new sfWidgetFormFilterDate( array(
‘from_date’ => new sfWidgetFormDate(),
‘to_date’ => new sfWidgetFormDate(),
‘with_empty’ => false)));
$this->setValidator(‘EnrolmentDate’, new sfValidatorDateRange(array(
‘required’ => false,
‘from_date’ => new sfValidatorDateTime(array(
‘required’ => false,
‘datetime_output’ => ‘Y-m-d 00:00:00′)
),
‘to_date’ => new sfValidatorDateTime(array(
‘required’ => false,
‘datetime_output’ => ‘Y-m-d 23:59:59′)))));
}

public function addEnrolmentDateQuery(Doctrine_Query $query, $field, $values) {
//add our join part
$query->leftJoin(sprintf(‘%s.Enrolment enrolment’,$query->getRootAlias()));

//set the where part depending on the value
if (isset($values['is_empty']) && $values['is_empty'])
{
$query->addWhere(‘enrolment.EnrolmentDate IS NULL’);
}
else
{
if (null !== $values['from'] && null !== $values['to'])
{
$query->andWhere(‘enrolment.EnrolmentDate >= ?’, $values['from']);
$query->andWhere(‘enrolment.EnrolmentDate <= ?’, $values['to']);
}
else if (null !== $values['from'])
{
$query->andWhere(‘enrolment.EnrolmentDate >= ?’, $values['from']);
}
else if (null !== $values['to'])
{
$query->andWhere(‘enrolment.EnrolmentDate <= ?’, $values['to']);
}
}
}

public function getFields() {
return array_merge(parrent::getFields(), array(‘EnrolmentDate’=>’EnrolmentDate’));
}

public function getTable() {
return new StudentStubTable();
}
}

// my stub table
class StudentStubTable extends StudentTable{
public function hasField($field) {
if($field == ‘EnrolmentDate’)
return true;
else
return parent::hasField($field);
}
public function getFieldName($field){
if($field == ‘EnrolmentDate’)
return ‘EnrolmentDate’;
else
return parent::getFieldName($field);
}
}
[/php]

If you have any remarks about my implementation (I am sure you have) don’t hesitate to tell me about, I think this code can still be improved.

Add properties to a relationship – Dealing with forms in symfony 1.4

Posted on by
Add properties to a relationship – Dealing with forms in symfony 1.4

Lately, I showed how you can a simply add properties to a relationship:

Doctrine 1.2: Add properties to a relationship

I continued to use this solution until I recently faced some issue for it. In fact, I discovered what I thought was a weird behavior until I completely understood the full impact of the solution.

Let’s take back our example:

N to N relationship with properties

N to N relationship with properties

I am using it in the symfony Framework, and I want to make a student form that includes also the enrolment properties. To do that, I can just use the embedded relation:

[php]
class StudentForm extends BaseStudentForm {
public function configure() {
$this->embedRelation("Enrolments");
}
}
[/php]

This way, symfony automatically takes care about including the collection of enrolments into my form. And process it after the submission.

You can simply include it in your template:

[php]
$form = new StudentForm();
echo $form;
[/php]

This is working pretty well!

The matter is that I want to customize my form, and thus I template it:

[php]
<form action="./submit" method="post">
<table>
<tbody>
<tr>
<th>Name</th>
<td><?php echo $form['name']->render() ?></td>
</tr>
<?php /* Include the collection of enrolments */ ?>
<?php foreach($form['Enrolments'] as $enrolment): ?>
<tr>
<?php echo $enrolment['enrolementDate']->render() ?>
</tr>
<?php endforeach; ?>
</tbody>
<tfoot>
<tr>
<td colspan="2">
<input type="submit" value="Save" />
</td>
</tr>
</tfoot>
</table>
<?php /* Don’t forget hidden fields */ ?>
<?php echo $form->renderHiddenFields() ?>
</form>
[/php]

Now, I have a fully customizable form… but it is not working when submit. Worse, it erases your enrolments!!! If you look into the doctrine log, I can see that you have a DELETE statement that should not be here. And then the update is done on your enrolments, even if they have been deleted.

At first, it is very strange. The reason why, is because when you embedded the enrolment relationship into your form, you also have indirectly embedded the course relationship. This is because the enrolment carries the course relationship. When symfony processes the form, it sees that you have enrolments, but you don’t have the courses that they should be bound to. So, it must be that your removed the course, and thus, the enrolments have no reason to exist anymore.

In order to work around this issue, you simply have to add the course into your form. I just did it with hidden inputs:

[php]
<?php foreach($form->getObject()->getCourses() as $course): ?>
<input type="hidden"
name="student[courses_list][]"
value="<?php echo $course->getid() ?>">
<?php endforeach; ?>
[/php]

Now, when symfony processes the form, it finds the courses ids and keeps the relationship intact.

You now have a good working form!

Doctrine 1.2: Add properties to a relationship

Adding actions to an auto generated admin in symfony 1.4

Posted on by
Adding actions to an auto generated admin in symfony 1.4

I know this functionality is nicely described in the symfony jobeet tutorial, but recalling this particular point emphasis the fact that symfony is definitely a good out of the box tool to easily generate powerful admin that should normally be very painful to code by hand.

In my example I will generate an admin for a system that deals with TV shows. The particular admin screen that I will customize is the TV Show list screen, in order to add it the “add season” action.
The “add season” action will simply add a season to my TV Show by retrieving the last season and increment the number and the year of the season.

Here is the UML for the TV Shows and the seasons:

UML of the tv show example

UML of the tv show example

We will first add the buttons to the admin interface, in order to do that I’ll just go to the generator.yml file and add the following lines:

[yml]
# /apps/backend/module/tvshow/config/generator.yml

generator:
class: sfDoctrineGenerator
param:
model_class: Tvshow
theme: admin
non_verbose_templates: true
with_show: false
singular: ~
plural: ~
route_prefix: tvshow
with_doctrine_route: true
actions_base_class: sfActions

config:
actions: ~
fields: ~
# customization of the list screen
list:
# header of the <table/>
display: [=Name]
# actions that will be in the combo box
batch_actions:
addSeason: ~
# actions that will be in the <table/>
object_actions:
addSeason: ~
_edit: ~
_delete: ~
filter: ~
form: ~
edit: ~
new: ~
[/yml]

You can note that the auto generated actions start with “_”, such as “_edit” and “_delete”. Moreover, the new “addSeason” action is automatically inserted in the screen and the routes and form submission are already working. You should obtain this:

Customized admin

Customized admin

Now we just need to code the actions that correspond to the route. Everything happens in the actions.calss.php dedicated to the tvshow generated module:

[php]
<?php

// /apps/backend/module/tvshow/actions/actions.class.php

require_once dirname(__FILE__).’/../lib/serieGeneratorConfiguration.class.php’;
require_once dirname(__FILE__).’/../lib/serieGeneratorHelper.class.php’;

class tvshowActions extends autoTvshowActions
{
/*
* Action executed when excecuting "addSeason" via the combo box
*/
public function executeBatchAddSeason(sfWebRequest $request)
{
// retrieving the ids correspondig to the checked boxes
$ids = $request->getParameter(‘ids’);

// query to retrieve the items via Doctrine
$q = Doctrine_Query::create()
->from(‘Tvshow t’)
->whereIn(‘t.id’, $ids);

// performing the addSeason on each TV show
foreach ($q->execute() as $tvshow)
$tvshow->addSeason();

// always inform the user
$this->getUser()->setFlash(‘notice’, ‘The selected TV Shows have been extended successfully.’);

// redirect to the auto generated module
$this->redirect(‘tvshow’);
}

/*
* Action executed when excecuting "addSeason" via the list directly
*/
public function executeListAddSeason(sfWebRequest $request)
{
// retrieving the tv show
$tvshow = $this->getRoute()->getObject();

// perform the addSeason
$tvshow->addSeason();

// always inform the user
$this->getUser()->setFlash(‘notice’, ‘The selected tv show have been extended successfully.’);

// redirect to the auto generated module
$this->redirect(‘tvshow’);
}
}
[/php]

Here we just miss the addSeason function:

[php]
<?php
// /lib/model/doctine/Tvshow.class.php

class Tvshow extends BaseTvshow {

/*
* Add a season the the TV show
*/
public function addSeason(){
// retrieve the last season via Doctrine
$last = Doctrine::getTable(‘Season’)
->createQuery()
->where(‘tvshowId=?’, $this->getId())
->orderBy(‘number DESC’)
->fetchOne();

// create the new one
$season = new Season();
$season->setTvshowId($this->getId());
$season->setYear($last->getYear() + 1);
$season->setNumber($last->getNumber() + 1);
$season->setNumberOfEpisodes($last->getNumberOfEpisodes());

// save it
$season->save();
}
}
[/php]

And everything is set. We now have a perfectly working new action included in our auto generated admin. This showing how symfony is highly customizable despite great functionalities in auto generated code.

Doctrine 1.2: Add properties to a relationship

Posted on by
Doctrine 1.2: Add properties to a relationship

I recentry had the need to had properties to a relationship using Doctrine. In fact this use case is not taken care of by the ORM (and ORMs in general) and there is no really good solution. Nevertheless, I found a not so bad way to implement such a pattern.

Here is what I’ll do:

As you can see, a very common school example.

We can already describe our objects and the N to N relationship.

[yml]
# Shema.yml
Student:
columns:
id:
type: integer
primary: true
autoincrement: true
name:
type: string
relations:
Courses:
class: Course
local: student_id
foreign: course_id
foreignAlias: Students
refClass: Enrolment

Course:
columns:
id:
type: integer
primary: true
autoincrement: true
name:
type: string

Enrolment:
columns:
student_id:
type: integer
primary: true
course_id:
type: integer
primary: true
[/yml]

In can now load the Doctrine task Doctrine_Core::generateModelsFromYaml to generate my model.

A good way to see I the generation went well is to open the generated base files and read the class comments. Let’s have a look:

[php]
/**
* BaseCourse
*
* @property integer $id
* @property string $name
* @property Doctrine_Collection $Students
*/
abstract class BaseCourse extends Doctrine_Record
{
// …
}

/**
* BaseEnrolment
*
* @property integer $student_id
* @property integer $course_id
*/
abstract class BaseEnrolment extends Doctrine_Record
{
// …
}

/**
* BaseStudent
*
* @property integer $id
* @property string $name
* @property Doctrine_Collection $Courses
*/
abstract class BaseStudent extends Doctrine_Record
{
// …
}
[/php]

You can see that all my classes have been load with the right properties. The interestig part here is to see that the student and Course classes is agnostic from the Enrolment class. Thus the couse already has a collection of students and the student a collection of courses.

So we have here a perfectly working N to N relationship. Doctrine takes care it self of the join operation when accessing the database.

Now, let’s had our properties on the enrolment relationship.

The idea here is to provide Doctrine a way to acces the enrolment class. The most simplier way to do that is to add the following relationships to the enrolment definition:

[yml]
Enrolment:
columns:
student_id:
type: integer
primary: true
course_id:
type: integer
primary: true
enrolementDate:
type: date
notnull: true
relations:
Course:
local: course_id
foreign: id
foreignAlias: Enrolments
Student:
local: student_id
foreign: id
foreignAlias: Enrolments
[/yml]

You can notice that I added the One to N relationships and the enrolmentDate property.

After a class generation we obtain :

[php]
/**
* BaseCourse
*
* @property integer $id
* @property string $name
* @property Doctrine_Collection $Students
* @property Doctrine_Collection $Enrolments
*/
abstract class BaseCourse extends Doctrine_Record
{
// …
}

/**
* BaseEnrolment
*
* @property integer $student_id
* @property integer $course_id
* @property date $enrolmentDate
* @property Course $Course
* @property Student $Student
*/
abstract class BaseEnrolment extends Doctrine_Record
{
// …
}

/**
* BaseStudent
*
* @property integer $id
* @property string $name
* @property Doctrine_Collection $Courses
* @property Doctrine_Collection $Enrolments
*/
abstract class BaseStudent extends Doctrine_Record
{
// …
}
[/php]

I now have the additionnal relationships and I can access my relationship class which has a new property: enrolementDate.

But, such a schem force us to change some way of working with the model.

Working with the model

The first thing that we need to keep in mind, is that if we add a student to a course or a course to a student by using the Course::Students and the Student::Courses collections, Doctrine will autogenerate the Enrolement object and save it. Thus we won’t have access to the enrolementDate field.

So instead of using the common way of adding element to a collection we should instantiate a Enrolement object, associate it with the course and student, and then save it. During this process we so have access to the enrolementDate.

[php]
$student = new Student();
$student->name = "Michel";
$student->save();

$course = new Course();
$course->name = "Programming 101";
$course->save();

//create the relationship
$enrolment = new Enrolment();
$enrolment->enrolmentDate = date(‘c’);
$enrolment->Course = $course;
$enrolment->Student = $student;
$enrolment->save();
[/php]

After that, I have a correct set of data in my database. I can also do some access:

[php]
//retrieve the courses
$courses = $student->Courses;

//retrieve the enrolments
$enrolments = $student->Enrolments;

//retrieve the course passing through and enrolment
$course = $student->Enrolments[0]->Course;
[/php]

The only matter is that I cannot access an enrolment given a student and a course.

Here is what I did to pass this issue. I simply added a function to my Student class that will generate the

[php]
class Student extends BaseStudent
{
public function getEnrolmentForCourse($course){
return Doctrine::getTable(‘Enrolment’)
->findOneByCourseIdAndStudentId(
$course->id,
$this->id
);
}
}
[/php]

As you can see, I simply use a magic function of doctrine. Even if the findOneByCourseIdAndStudentId function does not exist, Doctrine uses its name to generate the appropriate SQL query; I just need to fill the blanks with the ids of both objects.

Now I have a complete access to my enrolment object:
[php]
// find Michel
$student = Doctrine::getTable(‘Student’)->findOneByName(‘Michel’);
// take his first course
$course = $student->Courses[0];

// retrieve the enrolment data from it
$enrolment = $student->getEnrolmentForCourse($course);
[/php]

We saw here how to implement a full access to a relationship containing properties. It involves some schema description and a simple additional method in the classes’ code, but it imposes a specific way to create N to N relations. Thus it is not perfect; I hope this solution will help you working better with Doctrine.