Article: Doctrine Fixtures using a modular application structure
Monday, 18. May 2009
After configuring Doctrine migrations and models for a modular application structure, loading fixtures is really a piece of cake.
Fixtures are files with sample data records. They can be loaded during development, to always have something to play around with. We all know the horror of destroying your sample dataset when developing a delete method. Fixtures ease this problem, as we can reload that dataset any time. Doctrine uses YAML as the syntax for fixture definitions.
We will use Doctrine::loadData() to load the fixture files, which accepts two parameters. The first one is the path to the directory containing the fixture files. Sadly, we can't specify an array of paths here, as we did with Doctrine::loadModels(), so we have no choice but to loop through all directories:
<?php foreach ($fixtureDirectories as $directory) { Doctrine::loadData($directory); }
The only problem is, Doctrine kicks all the old db datasets for ...
Article: Doctrine Models using a modular application structure
Friday, 15. May 2009
With the hard part - migrations - already behind us, let us now take a look at modular model loading with Doctrine.
Loading the models
This is ridiculously easy, as the Doctrine method, that preloads all the models, takes one of two options. Either you can pass a directory path as string, or an array of directory paths to the method Doctrine::loadModels(). So your only have to collect all your model directories to an array an pass it to that method:
<?php $modelDirectories = someMagicGetterForTheModelDirectories(); Doctrine::loadModels($modelDirectories);
After that, it doesn't matter anymore, where the models are actually located.
Table generation
Another very nice feature of Doctrine is, that it can create the DB tables from the models - as long as you don't want to use migrations yet (prototype phase) that's a very useful feature.
The Method Doctrine::createTablesFromModels() is used for that purpose. In older Doctrine versions ...
Article: Doctrine Migrations using a modular application structure
Thursday, 14. May 2009
I'm currently integrating the Doctrine ORM with a Zend Framework based application.
Coming from the Django world I really prefer a modular application structure. The concept of one big application, where all the functionality resides is quite evil in my world.
Doctrine however is very application centric, although you can maneuver around most of the restrictions. A good example are migrations. Doctrine has excellent support for database migrations, but the bundled cli tool only allows you to configure a single path. That's no problem as the underlying class allows you to specify a directory, where the migrations reside.
<?php $migration = new Doctrine_Migration('/path/to/the/migrations/directory'); $migration->migrate();
So if you want to have more than one place to store the migration classes, simply loop through the directories:
<?php foreach ($migrationDirectories as $dir) { $migration = new Doctrine_Migration($dir); $migration->migrate(); }
So much for the theory, as this approach ...
Article: Some technical background on this website
Monday, 26. January 2009
As I have promised on the german section of my blog, I will give some technical background on the creation of this website.
Let me first give you some general facts:
- the site was built using Django 1.0
- as a Javascript library I use JQuery (currently the 1.3 release)
- for contend editing I use the Javascript based markItUp editor.
- the site is deployed with fabric.
The site makes heavy use of django pluggable apps. It is really great, how so many independent apps can work together with that few problems. When I encountered any (like marrying multilingual with localeurl), they were mostly solved with a few lines of code.
This blog uses the following external apps, not counting Djangos contrib:
- django-batchadmin: Mostly for mass deleting of spam comments (as soon as the bots find this site)
- django_extensions: This one I include in every project. A lot of really ...
Article: Newline as IFS on the Shell
Sunday, 25. January 2009
Maybe some of you already know this, but it took me a while to figure this one out, so not everyone seems to know.
On the shell the content of the Variable $IFS determines, what characters are used to separate chunks of input. Normally the shell uses any form of whitespace, which can lead to trouble.
Imagine, we want to cycle through a bunch of filenames with a for loop. The names are generated by a find command:
1 2 3 4 5 | #!/bin/bash for file in $(find /home -type f) do echo $file done |
We expect the shell to use the next filename for every loop. This works, but only if there are no spaces in the filenames. If we have some files that were created on a Windows system, some are guaranteed to contain spaces (you know, the infamous New Document.txt or the Program Files folder ...