(crossposted from Sebastian’s personal blog)

One of our clients needs to send emails with UTF-8 subject lines. Swift Mailer, which Symfony uses, makes this easy to do, but writing functional tests for it is another story. The problem is that, if non-ASCII characters are present in the subject line, Swift Mailer encodes them as required by RFC 2047 – for example, a string like “Transformación” turns into “=?utf-8?Q?Transformaci=C3=B3n?=”. How do we know that this is the right subject line?

There’s no immediately-available “convert this into a RFC 2047-compliant subject line” function, but we can get around this by making use of Swift_Message->toString and some choice preg functions.

First, create a dummy message containing the appropriate header. Swift_Message->toString() will contain our encoded header:

Next, we have to extract our encoded header – I’ve used preg_match() and a fairly simple regex.

Finally, now that the encoded header has been extracted, we need only wrap it in preg_quote() (because checkHeader() uses regex syntax) and test away.

Voila – now we can be confident that our test script can deal with Unicode email subjects.

First of all, my stored functions are in separate .sql files in my plugin’s data/sql/ directory in the interests of following convention within the project’s directory structure.

Secondly, in myPlugin/config/MyPluginConfiguration.class.php file, I have the following for the initialize() method.:

public function initialize()
{
  sfConfig::set("zz_myplugin_dir", $this->getRootDir());
  $this->dispatcher->connect("command.post_command", array($this, 'initializeStoredFuncs'));
}

We listen for the command.post_command event which we can then check to see if it’s a Doctrine insert-sql task being run. We also check to see if the function already exists before attempting to create it – if not, then carry on.

public static function initializeStoredFuncs(sfEvent $event)
{
  static $doneConfig = false;
 
  if ($doneConfig)
  {
    // Already done it.
    return;
  }
 
  if (!($event->getSubject() instanceof sfDoctrineInsertSqlTask))
  {
    // Not inserting any SQL. No point continuing
    return;
  }
 
  // Get database connection
  $con = Doctrine_Manager::connection();
 
  // Configure function 1
  self::addStoredRoutine($con, "myFuncName1", "myFuncName1.sql");
 
  // Configure function 2
  self::addStoredRoutine($con, "someOtherFunc", "someOtherFunc.sql");
 
  // Set config completed flag for later
  $doneConfig = true;
}
 
/**
* Adds a stored procedure into the database
*
* @param string $con Connection to use
* @param string $routineName Routine name
* @param string $routineFile Filename inside our [plugin dir]/data/sql/
*/
protected static function addStoredRoutine($con, $routineName, $routineFile)
{
  $options = $con->getOptions();
  $dsn = $options["dsn"];
  preg_match("/dbname=([^;]+)[;]?/", $dsn, $matches);
  $dbname = $matches[1];
 
  $sql = "SELECT COUNT(*) AS c FROM information_schema.routines WHERE routine_name = '{$routineName}' AND routine_schema = '{$dbname}'";
  try
  {
    $dbh = $con->getDbh();
  }
  catch (Exception $e)
  {
    // No database available - can't carry on
    return;
  }
 
  $resultSet = $dbh->query($sql);
  $results = $resultSet->fetch();
  if ($results["c"] == 0)
  {
    // Create the function
    $sqlRoutine = file_get_contents(sfConfig::get("zz_myplugin_dir") . "/data/sql/" . $routineFile);
    $con->getDbh()->prepare($sqlRoutine)->execute();
  }
}

I’m not a massive fan of the way the database name has been retrieved but it works for now :-) I’m pretty sure there’s a neater way of accomplishing the above too, but this is working consistently and allows the stored functions to become part of a plugin, so that if the plugin is removed at a later date, then any subsequent database builds will not have unnecessary routines hanging around.

function shorten($url, $login, $apikey)
{
  $api_url = "http://api.bit.ly/shorten?version=2.0.1&
                    longUrl=".urlencode($url)."&login=".$login."&
                    apiKey=".$apikey;
  $ret = file_get_contents($api_url);
  $data = json_decode($ret);
  if($data instanceof stdClass && property_exists($data, "errorCode") && $data->errorCode==0)
  {
    foreach($data->results as $result)
    {
      if(isset($result->shortUrl))
      {
        return $result->shortUrl;
      }
    }
  }
  return $url;
}

In the application where I am using this function I have defined the login name and api key as constants, so you can do away with 2 function calls.

Also handily it returns the original url if bit.ly fails.

The problem I discovered was that obviously Doctrine didn’t know what the conditional relationships were, since it was dependant on the type column. I researched some different approaches:

1. Doctrine’s RawSql

   This approach worked for generating the correct SQL query without a problem, but the issue then arose of how Doctrine could hydrate the result set. Answer was – it couldn’t :-) Well, I lie – I could use Doctrine::HYDRATE_SCALAR but I had issues with other related models, where I was joining to a table twice but under different aliases, which failed, since the scalar hydration would override earlier joins on the same table.

2. Column aggregation

   Column aggregation looked great initially – I could have a “TypeAEntry” and a “TypeBEntry”, and Doctrine would have handled the typing of the Entry automatically. I couldn’t however see a way to query “in reverse” – get all Entries and their associated models.

3. Write a raw SQL query, and use Doctrine’s PDO instance to retrieve the data.

Option 3) was the one I settled for in the end. It meant of course that I had to specify column names, and perform all the joins myself, but it did mean I could specify precisely what data I wanted back. This came back in the form of a normal array.  I’d tried to stay away from this option intially, but after spending too long researching the other 2 and hitting brick walls, I bit the bullet and dropped down to the raw stuff.  And hey presto!

Note – this approach will only work if you want the data to be read-only. If you want to then use Doctrine’s model goodness, you’ll need to work out how to transform that *back* into a model.

I know Dan, for example, doesn’t see the point of using Criteria because what is wrong with SQL?

I have sat and scratched my head a few times trying to figure out how to query using Criteria, I know how I would do it in SQL but I can sit for ages trying to bend Criteria to my will.

I really should have RTFM…

We do still recommend that you use SQL when it proves to be simpler, though.

Criteria is great when it fits your needs, but when it doesn’t or becomes very complex..stop step back and use SQL.

Using Propel 1.3 you get to use PDO and that is not something that is framework specific it’s an inbuilt PHP database abstraction layer. So the skills you learn using PDO are transferable to another project that doesn’t use a framework but uses a database.

So we have a custom query that we want to run and get back a bunch of user objects and we really don’t want to use Criteria…easy:

$name = “Wards”;
$bunchofusers = array();
//Our highly complex query….
//Fancy prepared stuff you get from PDO…think sprintf
$stmt = $con->prepare(“SELECT * FROM user WHERE last_name = ?”);
$stmt->bindValue(1, $name);
//erm execute…
$stmt->execute();
//Loop on our rows…and lets make some User objects..
while($row = $stmt->fetch()) {
$oUser = new User();
$oUser->hydrate($row);
$bunchofusers[]=$oUser;
}

Nothing really new to learn in the above code, it’s more like remembering that we can code how we choose too and we don’t have to be shackled to a certain way or slowed down by a framework when things don’t exactly fit.

** “What is Criteria?” I hear you say…well it comes with the Propel ORM, and it is for building up queries using objects rather than SQL. We use Propel within the symfony framework as our current ORM of choice.

It was simple to secure and NO ONE will ever know how I have done it.

MWHAHAHA

Auntie.
————-

Erm well I’m a bit stunned. I thought it would be something at least “clever” with cookies and javascript that was “the fix” that “secured” the iPhone version of the iPlayer. But no. All they are doing is checking the the user agent string again!

This time for the QuickTime user agent: “Apple iPhone v1.1.3 CoreMedia v1.0.0.4A93″

It does mean however that you can’t just use a browser based switcher but as I predicted someone had figured it out by the end of the day. 10 minutes to midnight.

Now I can’t seem to get Ruby working on my box but I may quickly knock up a PHP/libCurl version of this as its so simple.