From static …

Symfony allows the configuration of the mailer in its factories.yml. There smtp-settings can be definied. But in this case this is impossible as every client has different smtp-settings (every client can use its own smtp-settings to handle mailings).

As I did not want to create an instance of the Swift_Mailer (and Swift_SmtpTransport) myself I decided to create my own mailer-class which is derived from the symfony one. So I get the full benefits of logging.

… to dynamic

class myDynamicMailer extends sfMailer
{
  public function __construct(sfEventDispatcher $dispatcher, $options)
  {
    // Load client based configuration
    $cfg = EmailConfiguration::getCurrent();
 
    if(!$cfg->isSmtpConfigured())
    {
      $options["class"] = "Swift_MailTransport";
    }
    else
    {
      // Update settings for the current client
      $options["transport"]["param"]["host"]      = $cfg->getHostname();
      $options["transport"]["param"]["port"]      = $cfg->getPort();
      $options["transport"]["param"]["username"]  = $cfg->getUsername();
      $options["transport"]["param"]["password"]  = $cfg->getDecryptedPassword();
    }
 
    parent::__construct($dispatcher, $options);
  }
}

Simply update factories.yml with the new class and the dynamic configuration is applied.

all:
  mailer:
    class: myDynamicMailer
    # Rest follows here

Propel is dead

One thing got crystal clear during the talks. Propel is dead! In the next version 1.3 of symfony Doctrine will be the default orm. If thats not a hint … In symfony 2.0 Propel will be deprecated. Additionally the “leader of Propel” stated out that he is no longer leading Propel.

So its time to move to Doctrine. The new features in Doctrine 1.2 described by Jonathan Wage are quite nice. And Doctrine 2.0 will be even more impressive.

Sadly it will require a lot of work rewriting Propel “criteria queries” with Doctrine’s DQL-queries. But I’m certain that this step makes my applications future prove.

I’m using Propel 1.2 (an upgrade will be done soon) but for other people out there …

Consider the following declaration-fragment for the “Foo-entity”. Nothing special here.

<column name="name" type="VARCHAR" size="32" required="true" />
<column name="culture" type="CHAR" size="5" required="true" default="de_DE" />

Now if we create the new object and show the state (var_dump) of the object the culture-field is set to ‘de_DE’ which is correct.

$inst = new Foo();
$inst->setName('Foobar');
$inst->save();

But if you look in your (debug-)logfiles you will see that the insert-query will be generated as:

INSERT INTO foo (NAME) VALUES ('Foobar')

Where is the value for the culture column?

Propel keeps track of the modified columns to reduce the size of the update/insert-queries. The default values for the object will not be set through the generated class-methods. Instead the default values are directly assgined in the member-variable of the generated class. So Propel is unaware that the values has changed.

protected $culture = 'de_DE';

Conclusion

I don’t know if this bug is fixed in Propel 1.3. Soon I will know …

As I will continue working with Propel 1.2 in the current project the “workaround” is to manually set the culture. This is best done in the constructor of your derived class. So Propel knows that the column is modified.

class Foo extends BaseFoo
{
  public function __construct()
  {
     // Note: The generated base-class does not have a constructor
     // so parent::__construct will fail!
     $this->setCulture($this->getCulture());
  }
}

The plugin ships with XLIFF-files for interface translation. In order to get gettext working simply create the required directories inside the plugin-directory (plugins/sfAssetLibraryPlugin/modules/sfAsset/i18n) and create a new catalog for each language (de, en, fr, ...).

The important thing here is to take care of the “translation-namespace” the plugin uses (sfAsset in this case).

echo __('Description', null, 'sfAsset');

Directory layout of the sfAssetLibraryPlugin

Propels (Creole) “criteria infrastructure” is a great speed-up for the development process and makes it easy to “write” queries. However if you are forced to create a SQL-Join which requires multiple join-conditions the criteria-api is not a helper anymore.

In order to make use of the criteria-api even in this case a “hack” can be used. Someone else described it in a blog-post.

$c = new Criteria();
$c->addJoin(Object1Peer::ID, Object2Peer::ID .
  ' AND ' . Object1Peer::LOCALE . ' = ' . Object2Peer::LOCALE .
  ' AND ' . Object1Peer::WHATEVER . ' = ' . Object2Peer::WHATEVER,
  Criteria::JOIN);

Its a “hack” but you are not required to write the whole sql-query on your own and can rely on the criteria-api.

As I found out the Propel-developers are aware of this problem and a solution is planned for the (hopefully soon) next Propel release 1.4.

public function executeSomething ()
{
  $this->getResponse ()->setHttpHeader ('Content-Type', 'application/json');
  // ... Do something
  return $this->renderText ($myJsonCode);
}

Nothing spectacular. This code works with Opera, Firefox and Safari. The application/json is the official Mime-Type for JSON.

Save as …

If you call this action via your JavaScript-code with the famous Internet Explorer (IE7 in this case) the “Save as …” – dialog appears and IE wants me to save a file! What?!

Workaround

The reason behind this is that Internet Explorer cannot associate the application/json Mime-Type to an application installed on the client-side.
To get around this simply use text/javascript as Content-Type inside Symfony.

public function executeSomething ()
{
  $this->getResponse ()->setHttpHeader ('Content-Type', 'text/javascript');
  // ... Do something
  return $this->renderText ($myJsonCode);
}

Conclusion

I love IE!

Symfony makes heavy use of Propel. Propel finds objects in the storage container using criteria. If you want to let Propel (okay the database) ignore the case you can set this in the criteria.

$c = new Criteria ();
 
// Allow case sensitive searches
$c->setIgnoreCase (true);
 
// Find all posts which name contains propel
$c->add (BlogPostPeer::NAME, 'Propel');
 
$posts = BlogPostPeer::doSelect ($c);

Because PostgreSQL (unlike MySQL) does not support collations to easily manage how comparisons of strings are done Propel has to generate this sql-statement.

SELECT blog_posts.name, blog_posts.date
FROM blog_posts
WHERE UPPER(blog_posts.name) = 'PROPEL';

Depending on your amount of data this can become very slow even if you have an index defined for the "name"-column.

The trick is to create another index for the column "name".

CREATE INDEX "UpperNameIndex" ON blog_posts USING BTREE (UPPER(name));

Thats it. When now using setIgnoreCase its fast again.