Definitely interesting stuff going on there, especially the preview release of Symfony 2.0 whose code is available on GitHub since a couple of weeks and which makes major changes to the “good old way” one used to write symfony applications (actions are now “controllers” and extensions “bundles” and well, a dozen of other things changed as well of course… you can read everything in detail here).

Also, Doctrine 2.0 seems to be the first PHP ORM which decouples the modelling approach from the actual database abstraction layer, skips the need for base classes and enables the model definition via annotations. Also, they seem to fight against the overly complex magic from Doctrine 1.x (one of my top complaints on Doctrine in comparison to, f.e. Propel) – maybe I’ll revisit Doctrine again when the next version gets stable.

The guys at Sensio labs do really have a fast development pace and I get more and more the impression that the Symfony ecosystem is the major competitor for the Zend framework. Community-wise I think Symfony is already much bigger than any other PHP framework.

It was a costly lesson today when I tried to reimport a dump of a couple of Sympal tables. One of them, the one which models the menu items, has a nested set behaviour, and apparently this one cannot be restored properly by doctrine:

[Doctrine_Record_UnknownPropertyException]

  Unknown record property / related component "children" 
  on "sfSympalMenuItem"

Apparently this particular issue popped up a couple of times in the past for other people as well (Google for it) and while the help of doctrine:data-dump still (Doctrine 1.2) blatantly states

 The doctrine:data-dump task dumps database data:

./symfony doctrine:data-dump

The task dumps the database data in data/fixtures/%target%.

The dump file is in the YML format and can be reimported by using the doctrine:data-load task.

./symfony doctrine:data-load

(with the emphasis of “can be reimported”)

the author of Doctrine, Jonathan Wage, told me today on Sympal’s IRC (shortened):

<jonwage> we don’t want people to think you can dump and then restore <jonwage> that is not what the data fixtures are for <jonwage> b/c dumping and then loading will never work <jonwage> an ORM modifies data on the way and and the way out <me> I mean the least thing doctrine could do there is that if it detects the nested set behaviour it should error out clearly on dump <jonwage> so you can’t dump the data through an ORM and then try and reload it <jonwage> i.e. hashed passwords <me> if dumping is “never” going to work – why do you support dumping into yaml at all?! <jonwage> if we do that then we would have to throw errors in sooooooo many other cases too <jonwage> because it is at least a little bit of a convenience <me> its like a half-baked feature then <jonwage> we dump the raw data <jonwage> and you can tweak it <jonwage> thats my point though, it will ALWAYS be a half baked feature thats why we document it that way <jonwage> it can NEVER work 100% the way you want it to <jonwage> so if we fix that one thing, a million other things will be reported that we cannot fix <jonwage> bc an ORM is not a backup and restore tool <jonwage> it is impossible

Now I know that as well. My only problem was that I struggled “what is wrong with my fixtures” the whole time and never dared to ask “what is wrong with doctrine”…

Getting the logger in web context is easy, all you have to do is

but its a little harder to do for the command line task.

By default no symfony context is created for a command line task and even if it is created, the above call returns an instance of sfNoLogger. Logging in command applications happens through the sfTask::logSection() method, which basically throws an event at the created dispatcher in SYMFONYDIR/lib/command/cli.php. There you can also see that an instance of sfCommandLogger is created, but there is no way to get your fingers at this instance, because its purely local.

So what can we do? Parametricizing the business method with the sfTask instance and using the logSection() is obviously no solution, because this would break in web context where no such sfTask instance exists…

My solution was a bit more straight forward – I simply decided to not use the task-supplied logging schema at all, but created my own logger like this:

Hope this helps somebody.

Well, not by me. Doctrine seems to have a couple of very good concepts, amongst them built-in validators, a powerful query language, and last but not least, an easy schema language. (Though to be fair, Propel will gain most of these useful things in the future as well or already has, f.e. with its PropelQuery feature.)

But Doctrine also fails in many areas; the massive use of overloads everywhere makes it very hard to debug and even worse, it tries to outsmart you (the developer) in many areas, which makes it even more hard to debug stuff which Doctrine doesn’t get right.

A simple example – consider this schema:

(I’ll skip the relation setup here, Doctrine should find them all with an additional detect_relations: true)

So what do you expect you see when you call this?

Well, I expected to get an empty object, with a NULLed foo_id and bar_id, but I didn’t! For me foo_id was filled with a 1. Wait, where does this come from?

After I digged deep enough in Doctrine_Record, I saw that this was automatically assigned in the constructor, coming from a statically incremented $_index variable. I could revert this by using my own constructor and call assignIdentifier() like this:

but now this object could no longer be added to a Doctrine_Collection (which is a bummer, because if you want to extend object lists with “default” empty objects, you most likely stumble upon a Doctrine_Collection, which is the default data structure returned for every SQL query).

So you might ask “Why the hell does all this impose a problem for you?”

Well, if you work with the FooForm created by the doctrine plugin for you in Symfony and you want to add FooBarBazForm via sfForm::embedFormForEach a couple of times (similar to the use case described here), you suddenly have the problem that your embedded form for the appended new FooBarBaz object “magically” gets a foo_id of a wrong (maybe not existing) Foo object and you wonder where the heck this comes from…

I have my lesson learned for the last one and a half days. I promise I’ll never ever create a table in Doctrine with a multi-key primary key again and I’m returing back to Propel for my next project.

append domain-name " company.local other.company.local";

So whenever your DHCP server doesn’t provide these information (the one in my company does not), it’ll add this

domain company.local
search company.local other.company.local

to your /etc/resolv.conf.

SQLSTATE[HY000]: General error: 2014 Cannot execute queries
while other unbuffered queries are active. Consider using 
PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against
mysql, you may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.

So, yes, I already have PDO::MYSQL_ATTR_USE_BUFFERED_QUERY set to TRUE, so why is PDO still complaining? And especially why it is complaining now, because the same code which triggered the error today ran without problems for the past 9 months?

After struggling a lot I found the cause: I missed to close a statement which was reused in a loop!

So take care that you always call PDOStatement->closeCursor() in use cases like this:

$stmt = $con->prepare("SELECT * FROM doodle WHERE id = ?");

foreach (range(1,10) as $id) { $stmt->execute(array($id)); $row = $stmt->fetch(); $stmt->closeCursor(); }

Anyways, today at work I was so sick of the problem that I decided should hack something together. Here is the result:

#!/bin/bash
export LANG=C
if [ $# -ne 2 ]
then
    echo "Usage:" $(basename $0) "<old> <new>"
    exit 1
fi

old=$1 new=$2 repo_root=svn info | grep "Repository Root" | cut -f3 -d" ";

if [ -n "$(svn info $repo_root/$new 2>&1 | grep "Not a valid URL")" ] then echo "$repo_root/$new is not a valid URL" exit 1 fi

for ext in $(svn st | grep -e "^X" | cut -c 8- | xargs -L1 dirname | uniq) do externals=$(svn propget svn:externals $ext) if [[ "$externals" == $repo_root/$old ]] then externals=${externals//$repo_root\/$old/$repo_root\/$new} svn propset svn:externals "$externals" $ext fi done Save this into a file, make it executable and you’re good to go! The script is smart enough to check if the target URL (based on the repositories’s root and the given <new> path) actually exists and also only changes those external definitions which actually match the repository root.

Fun!

So yeah, rendering the complete login mask HTML as partial to the client is stupid, but also relatively easy to fix:

public function executeLogin($request)
{
    if ($request->isXmlHttpRequest())
    {
        // renderJSON is a custom function which json_encode's
        // the argument and sets an X-JSON header on response
        return $this->renderJSON(array("error" =>
                                    "Your session expired"));
    }
    ...
}

This was of course only half of the fix. I still had to handle this (and other) special JSON response on the browser’s side:

new Ajax.Request("mymodule/myaction", {
     onSuccess: function(response, json) {
         if (json.error)
         {
             // display the error
             alert(json.error);
             return;
         }
         // the actual callback functionality
     }
}

Uh, anyone screams “spaghetti code”? Yeah, you’re right. I quickly headed for a more general implementation, also since we can’t do that for a couple of symfony-specific prototype helpers anyways, like update_element_function, whose Javascript code gets generated by Symfony dynamically. So how can this be generalized?

Ajax.Responders to the rescue

Actually, prototype already contains some kind of “global hook-in” functionality for all Ajax requests triggered by the library: Ajax.Responders.

While this seemed to support all common callbacks (among them onCreate, onSuccess, onFailure and onComplete), some testing showed though that f.e. the onComplete callback was always called after the specific AJAX request’s onComplete callback, so this was pretty useless for me. After all, I also wanted to prevent that the specific callback gets executed when I encountered an error…

After diving through prototype’s code for some hours I found a solution. Particularily helpful here is that prototype signals every created Ajax request to the onCreate handler and gives the request and response object handling this request as arguments to it. Time to overwrite prototype’s responder code! Here is it:

Ajax.Responders.register({
    onCreate: function(request) {
        var oldRespondToReadyState = request.respondToReadyState;
        request.respondToReadyState = function(readyState) {
            var state = Ajax.Request.Events[readyState];
            var response = new Ajax.Response(this);
            var json = response.headerJSON;

        if (state == 'Complete' && json && json.error)
        {
            alert(json.error);
            return;
        }
        oldRespondToReadyState.call(response.request, 
                                       readyState);
    }
}

});

Another particularily useful piece of knowledge I gathered today to let this work is how Function.prototype.call and Function.prototype.apply work (both are available since Javascript 1.3). Basically they allow the execution of a function in scope of the object given as first parameter (there is a nice introduction available here).

If you’ve ever wanted to “send an event to some object to make its listener fire” because the listener’s code depended on the fact that the this reference points to the object the event was fired upon, you should now have a viable alternative:

Event.observe(myObj, 'click', myHandler);
// is call-wise equivalent to
myHandler.call(myObj);

No need to create custom mouse events and throw them around any longer…

So, being a little kid with these things sometimes in terms of being not able to wait for stuff to happen, I did this one thing what one really should not do at all: Touching a running system.

I backed up all important stuff to a special directory inside the virtual machine and told the automatic installer procedure to start installing Ubuntu 8.04 LTS. After approximately two hours my working setup was gone. No emailing, no webserver, nothing.

So I started with a clean ubuntu server instance from scratch yesterday evening and it took me the whole last night to get some things working. While the mail setup is still a beast (need to read myself into exim and try out a couple of tutorials), I’m already quite proud of my Apache / FastCGI PHP setup. I copied a lot of ideas from the www setup at work where we have implemented separated, secured V-Host users, suexec-protected php wrappers and more. Tonight I added another little puzzle piece into the mix: SFTP/SCP access for individual users to their virtual hosts.

Again, the Ubuntu community was very helpful – I found a HOWTO for getting an sftp server up and running in a jailed environment. There was actually very little I had to change so it fitted my use case – instead of using /home/chroot as jail, I put the jail into /var/www/vhostjail and all websites / vhosts which should get file transfer access below that directory. The biggest plus with this setup – beside the security point (people can only sftp or scp to the jail and cannot break anything on the rest of the system) – is now that the user who uploads files and the webuser who executes the request (i.e. the Apache user) is one and the same. No need to make files world-readable or even -writable when setting up a web application which has to read or write data. No need to change the owner or the access of uploaded files because the webuser could otherwise not read, write or execute them.

Wow. I like that setup.

Now, if only exim would so easy to understand and master…