all:
  .settings:
    timeout:    false

Here's the short way:

class myUser extends sfBasicSecurityUser
{
  public function initialize($context, $parameters = null)
  {
    if (sfConfig::get('sf_timeout') == 0) {
      // session will expire if window is open for a day
      sfConfig::set('sf_timeout', 86400);
    }

    return parent::initialize($context, $parameters);
  }
}

class myUser extends sfBasicSecurityUser
{
  public function initialize($context, $parameters = null)
  {
    $this->context = $context;

    $this->parameterHolder = new sfParameterHolder();
    $this->parameterHolder->add($parameters);

    $this->attributeHolder = new sfParameterHolder(self::ATTRIBUTE_NAMESPACE);

    // read attributes from storage
    $attributes = $context->getStorage()->read(self::ATTRIBUTE_NAMESPACE);
    if (is_array($attributes))
    {
      foreach ($attributes as $namespace => $values)
      {
        $this->attributeHolder->add($values, $namespace);
      }
    }

    // set the user culture to sf_culture parameter if present in the request
    // otherwise
    //  - use the culture defined in the user session
    //  - use the default culture set in i18n.yml
    if (!($culture = $context->getRequest()->getParameter('sf_culture')))
    {
      if (null === ($culture = $context->getStorage()->read(self::CULTURE_NAMESPACE)))
      {
        $culture = sfConfig::get('sf_i18n_default_culture', 'en');
      }
    }

    $this->setCulture($culture);

    // read data from storage
    $storage = $this->getContext()->getStorage();

    $this->authenticated = $storage->read(self::AUTH_NAMESPACE);
    $this->credentials   = $storage->read(self::CREDENTIAL_NAMESPACE);
    $this->lastRequest   = $storage->read(self::LAST_REQUEST_NAMESPACE);

    if ($this->authenticated == null)
    {
      $this->authenticated = false;
      $this->credentials   = array();
    }
    else
    {
      // Automatic logout logged in user if no request within [sf_timeout] setting
      if (0 != sfConfig::get('sf_timeout') && null !== $this->lastRequest && (time() - $this->lastRequest) > sfConfig::get('sf_timeout'))
      {
        if (sfConfig::get('sf_logging_enabled'))
        {
          $this->getContext()->getLogger()->info('{sfUser} automatic user logout due to timeout');
        }
        $this->setTimedOut();
        $this->setAuthenticated(false);
      }
    }

    $this->lastRequest = time();

  }
}

class myUnitTest extends sfPropelTest
{
  public function setup()
  {
    $this->bob = UserPeer::retrieveByPK('bob');
  }

  public function teardown()
  {
    $this->diag('Test method complete!');
  }

  public function test_user()
  {
    $this->is($this->bob->getId(), 'bob', 'Bob exists!');

    $user = new User();
    $user->setFirstName('Joe');
    $user->setLastName('Smith');
    $user->setUsername('joe');
    $user->save();

    $joe = UserPeer::getBy(UserPeer::USERNAME, 'joe');
    $this->isa_ok($joe, 'User', 'Joe exists!');
  }

  public function test_dataDelete()
  {
    $this->is($this->bob->getId(), 'bob', 'Bob still exists!');

    $joe = UserPeer::getBy(UserPeer::USERNAME, 'joe');
    $this->ok(!$joe, 'Joe no longer exists.');
  }
}

$test = new myUnitTest();
$test->execute();

If you've written tests in Ruby on Rails, the above should look familiar. If not, let's go through the code:

The first two lines are setup: The first line tells symfony what application to test - in this case, "myApp" - and the second line includes the code we need to test against the database. Next we define our "test case" - a class that extends sfPropelTest, which is itself a child of lime_test. Every method that begins with "test_" will be called in turn, with our test data being reloaded between each call. Also, the setup() method, if defined, will be called immediately before each test method, and the teardown() method, if defined, will be called immediately after. The last two lines create a new instance of our test suite, and call its execute() method, which runs our tests.

There you have it - a quick and painless way to run unit tests in symfony. One less excuse for not writing them!

The default Propel builders can be found in the symfony source in these places:

symfony/addon/propel/builder/sfObjectBuilder.php
symfony/addon/propel/builder/sfPeerBuilder.php

The classes these inherit from are buried. They can be found here:

symfony/vendor/propel-generator/classes/propel/engine/builder/om/php5/PHP5ComplexObjectBuilder.php
symfony/vendor/propel-generator/classes/propel/engine/builder/om/php5/PHP5ComplexPeerBuilder.php

First, we have to tell our Flash component what the cookie is, so it can roll it into the URL. One solution would be to pass the session cookie as an argument in FlashVars, but then the user's session cookie is sitting unencrypted in the HTML, leaving them vulnerable to cross-site request forgery. Better to use javascript to fetch the cookie, and then put it in FlashVars. If you are using ufo.js, the first argument to UFO.create() should look like this:

{
  movie: '/flash/uploader.swf', 
  id: 'uploader',
  name: 'uploader',

  flashvars: 'cookie=' + document.cookie,

  // other options ...
}

Note that if you are dealing with multilple cookies, you will want to parse the output of document.cookie and send only the desired cookie.

Next, add the cookie to the URL in your ActionScript (this is for ActionScript 2.0):

var list:Array = myFileRefList.fileList;
var item:FileReference;
var url:String = _root.uploadURL + '?cookie=' + _root.cookie;

for (var i:Number = 0; i < list.length; i++) {
  item.upload (url);
}

That does it for the client side. Now, we need to tell PHP to use our cookie instead of the one the browser sent. This does the trick:

list($cookieName, $cookieValue) = str_split('=', $_GET['cookie']);

session_name($cookieName);
session_id($cookieValue);

session_start();

If you are using symfony, things are a little more complex. We need to call session_name() and session_id() before session_start(); looking at the symfony source code, we find that session_start() is called in sfSessionStorage::initialize(). So a simple solution is to extend the sfSessionStorage class:

class mySessionStorage extends sfSessionStorage
{
  public function initialize($context, $parameters = null)
  {
    if ( /* whatever the condition is when we want to do this */ ) {
      if ($cookie = $context->getRequest()->getParameter('cookie')) {
        $name = 'symfony';
        preg_match('/^' . $name.'=(.*)$/', $cookie, $asMatch);
        $value = $asMatch[1];

        session_name($name);
        session_id($value);
      }
    }

    parent::initialize($context, $parameters);
  }
}

Finally, tell symfony to use the mySessionStorage class by editting factories.yml:

all:
  storage:
    class: mySessionStorage
    param:
      session_name: symfony

And you're done! Clear your cache, and try it out. An easy way to check if it's working is to add the following line to the end of index.php (or frontend.php):

file_put_contents('testSessionOverwrite.txt', sfContext::getInstance()->getRequest()->getActionName());

Now try uploading a file. If the action name in testSessionOverwrite.txt is the action you're uploading to, you're golden. If instead it is the name of the action that authenticates users, you have a problem somewhere, and you get to have the enjoyable experience of debugging PHP without browser output. Remember to erase the debugging line from your front controller when you get everything working.

Next time, just make the users upload their damn files one-at-a-time...

If you doubt the importance of this distinction - and I understand why you might - check out the following, rather shocking examples taken from the PHP manual:

if (            0 == 'my string'
  &&            1 != 'my string'
  &&       '+010' == '10.0'
  &&   '  131e-2' == '001.3100' 
  && '000e002073' == '0e459239'
  &&       '0xab' == 0253 
  &&       '0xab' != '0253' 
  &&       '0xab' == '171'
){
  echo 'WTF????';
}

In light of these facts, a developer should only ever use == when type-conversion is expected, such as when comparing a form input to a numerical value. Furthermore, we should regard == as expressing this expectation, since, by using the comparison operator, the developer has forced us to check for conversions. Thus, to keep your code clean and self-documenting, stop using ==. Use strcmp() for strings; it's binary-safe, and expresses the type of your arguments without the need for comments. Use === for everything else.

Suppose we write the following code, whose simple purpose is to go through an XML document and replace every "foo" element with an empty "bar" element:

$dom = DOMDocument::loadXML('
  <root>
  <foo>This</foo>
  <foo />
  <foo />
  </root>'
);

$document = $dom->documentElement;
$foos = $document->getElementsByTagName('foo');

for ($i = 0; $i < $foos->length; $i++) {
  $bar = $dom->createElement('bar');
  $document->replaceChild($bar, $foos->item($i));
}

<root><bar/><foo/><bar/></root>

The solution to this problem is to save a reference to each node in an array, then loop over the array:

for ($i = 0; $i < $foos->length; $i++) {
  $nodes[$i] = $foos->item($i);
}

for ($i = 0; $i < count($nodes); $i++) {
  $bar = $dom->createElement('bar');
  $document->replaceChild($bar, $nodes[$i]);
}

<root><bar/><bar/><bar/></root>

Implementation: A DOMNodeIterator Class

It's best to encapsulate this technique in a class. Here's a simple class that does the job:

class DOMNodeIterator implements Iterator
{
  protected $nodes;

  public function __construct(DOMNodeList $nodeList)
  {
    if ($nodeList->item(0)) {
      for ($i = 0; $i < $nodeList->length; $i++) {
        $this->nodes[$i] = $nodeList->item($i);
      }
    }
  }

  public function current()
  {
    return current($this->nodes);
  }
    
  public function key()
  {
    return key($this->nodes);
  }

  public function next()
  {
    return  next($this->nodes);
  }

  public function rewind()
  {
    reset($this->nodes);
  }

  public function valid()
  {
    return $this->current() ? true : false;
  }
}

On the Other Hand, Orphan Nodes

Our iterator has one drawback: if we remove a node in the list via removeChild(), it will still exist in the iterator, but it will no longer be associated with our document. Unfortunately, the only way to check for this is to ascend the entire DOM tree each time we want to access a node, to make sure it is still a descendant of the root node. Rather than incur that overhead, we'll leave it to the devloper to use the iterator with care. We can safeguard the above code by putting the call to replaceChild() inside a try block:

try {
  $document->replaceChild($bar, $foo);
} catch (DOMException $e) {
  if ($e->getMessage() !== 'Not Found Error') {
    throw $e;
  }
}

An Issue with PHP, or with DOM?

Stay tuned for my next blog entitled "Why the DOM Sucks." Till next time…

<?php echo $something ?>

is replaced by the elegant and readable

<%= something %>

The very good news is that you can use these same tags in PHP! Just add the following to your htaccess:

php_flag asp_tags on

Voila! Readable templates. What's curious is that no one seems to use this option. Perhaps it is because they are referred to as "ASP-style tags." (Can we just call them "Ruby-style tags", instead?) On all my sites, I use the long tags for blocks of code, and the short <%= %> tags for any PHP code floating in the HTML sea. In symfony, that means the template files use one tag-style, and the rest of the code uses the other. I encourage everyone – yes, everyone – to start using Ruby-style tags in their templates. The more people use it, the more common it will be to have the "asp_tags" option on by default, so people on shared servers can join in the readable fun.

It's important for a second reason – arbitrary conventions should be standardized. That is, any time we are faced with a set of possibilities that are all of equal value – such as what weird punctuation our programming language should use to demarcate itself – we should pick one standard way and stick with it. That way we reduce the learning curve of all languages (or whatever the things the convention pertains to). Imagine if there were one, universal syntax for putting server-side code into HTML. Imagine if there were a templating language that every designer knew – because it's so simple – and that every server-side language supported. It would not be a universal programming language, since we should not be using the full power of a programming language from inside our templates; that's what the controller code is for. This universal templating language (What the hell, let's go ahead and call it UTL, because giving initials to computer-denizens makes them seem like real people) should support the following things, and probably nothing else:

1. Variables, including objects and arrays
2. if/else
3. while
4. foreach
5. Very basic arithmetic and string operators
6. No function or method calls

Make the dream a reality. Start by using Ruby tags.

Interfaces have a single purpose: by using them, functions and methods can require their arguments to implement a certain set of methods. (Actually, they merely require that methods matching certain definitions exist.) Suppose we are writing a graphics library, and we have a set of functions for manipulating and drawing objects that have a color. In that case, we may want to have an interface like the following:

interface DrawableInColor 
{ 
  public function getColor(); 
  public function setColor($color); 
  public function draw($x, $y); 
}

But suppose we also want to deal with objects that can be resized. Then we may want an interface like this:

interface DrawableAndResizable 
{ 
  public function scaleX($x_factor); 
  public function scaleY($y_factor); 
  public function draw($x, $y); 
}

So what if we have a classof objects that are colored and resizable? So long as we give the class's methods the appropriate names, the class will be an implementation of both the above interfaces. There is no ambiguity, since there is only one method named "draw." In fact, no class can have two functions by the same name, so there can never be ambiguity in declaring that a class implements two overlapping interfaces. But we can't declare it! To use our class with both sets of functions, we would need to remove the functions' interface requirements entirely. The only other solution is to rename the draw() function of one of the interfaces (to draw2(), let's say) and add a dummy function to our class, like this:

public function draw2($x, $y) 
{ 
  $this->draw($x, $y); 
}

Both "solutions" are terribly ugly, and although the core developers of PHP insist that it is not an object-oriented language, it should at least allow the OO features of the language to be used as such. The restriction on interfaces severely limits their utility in PHP, and the development team should really consider removing it in future releases.