I completely loathe Zend_Form and it’s silly validation system, but I’ll save that for another time and just concentrate on a specific example: You can only have one validation callback per form element.

There’s the awesome Zend_Validate_Callback which allows us to try to make up for other validation shortcomings by allowing us to define our own validation rules.

But apparently you can only add one callback validator per form element.

Why is this an issue?

Zend_Validate_Callback provides silly error messages (“% is not valid”). So it’s desirable to override this message, but if you’re doing multiple custom validations, you’ll want multiple messages depending on how validation failed. Well, you can’t add multiple messages, so the intuitive (as close as you can get to intuitive with ZF) thing to do would be to break it out into multiple validators and add a helpful message for each. You can’t do that!

Thanks, ZF.

A possible solution would be to pass an instance of the object to the callback via setOptions(). But the messages are private, with no method to change them.

Hackish solution: create our own validator.

<?php
require_once 'Zend/Validate/Abstract.php';
require_once 'Zend/Validate/Callback.php';
 
class My_Validate_Callback extends Zend_Validate_Callback
{
 
    public function setMessage($message, $value)
    {
        if(isset($this->_messageTemplates[$message]))
            $this->_messageTemplates[$message] = $value;
    }
 
    public function isValid($value)
    {
        $this->_setValue($value);
 
        $options  = $this->getOptions();
        $callback = $this->getCallback();
        $args     = func_get_args();
        $options  = array_merge($args, $options);
 
        $options[] = &$this;
 
        try {
            if (!call_user_func_array($callback, $options)) {
                $this->_error(self::INVALID_VALUE);
                return false;
            }
        } catch (Exception $e) {
            $this->_error(self::INVALID_CALLBACK);
            return false;
        }
 
        return true;
    }
}

All we’re doing here is extending Zend_Validate_Callback and (1) adding a method to override the message templates and (2) passing a reference to this object to the callback method.

Complex. Insane. Should be unneeded. Zend Framework.

See if you can spot the logic error:

<?php
    require_once "mnnl.pnnl";
 
    $tkkl = new $fkkl($_POST["wkkl"]);
 
    $tkkl->pkkl()->jkkl(14, 15, blt);
 
    foreach($tkkl->lkkl($tkkl::BkklBokkl) as &$jkkl)
    {
        jkkljokkl($jkkl);
 
        if($jkll->brkll == blt)
            hbblhobbl($jkkl);
 
        $skzzl = "SELECT fkkl, fakkl FROM frzzlz WHERE frzzlor = 'fazzor' AND fwippl IS NOT NULL";
 
        $hobbl = new hobblDobbl(hobblDobbl::$swbbl("fraaa"));
 
        $hobbl->hwaah($skzzl);
 
        $jkkl->hzrnn($hobbl->fkkl, $hobbl->fakkl);
 
        $tkkl->znnado($jkkl->twng);
    }
 
    $mbnf->swmlel($tkkl->ploo());
?>

Yesterday, while trying to figure out the best way to deal with PostgreSQL arrays in PHP, I came across the new str_getcsv() function in PHP as of 5.3. This function works much the same as fgetcsv to parse a CSV line, except that it works on a string instead of a file.

For quick reference, CSV looks like this:

"My Name",14,"32,000","2009-04-15"

And the return value of a PostgreSQL array looks like this:

{"My Name",14,"32,000","2009-04-15"}

Notice the similarities?

We can use PHP’s trim and str_getcsv to turn this PostgreSQL array into a PHP array:

<?php
    $data = str_getcsv(trim($record->value, "{}"));
?>

Simple as simple does. As long as your array has only a single dimension. If you’re using multidimensional arrays in PostgreSQL then you’re dead to me.

At first when I saw the Zend Framework recommendation of omitting the closing tag in PHP files I thought it bizarre and stupid. Afterall, you close every other syntactic character in programming: parenthesis, brackets, HTML tags, ifs, loops, etc. So why wouldn’t you close the PHP tag at the end of the document as well?

The Zend Framework reason is, of course, to white space data from being sent to the browser prematurely, which messes up sending header information to the browser. My first thought was “this is lazy and encourages bad coding.”

But the more I think about it, the more it makes sense. It isn’t laziness, but a fool proof way to prevent a common mistake from happening. And apparently the closing tag isn’t required at all, so why not?

I don’t think I’ll be quick to adopt this practice, but maybe eventually, and maybe as I write new code. We’ll see.

Gentoo, ffs, get PHP 5.3.1 in Portage ASAP. PHP 5.3 isn’t even in there, yet. What’s the use of your package manager if I just have to manually install stuff?

/rant

When writing applications that are meant to be used by users the world over (not just users within a localized network), it’s important to be able to show dates and times relative to the users time zone. If one user posts something at 11:30 EST, and a few minutes later, a user in California checks the post, it would look as if it were made in the future. Not cool.

Lucky, it’s quite easy to localize dates and times using PHP’s built in date classes.

Continue Reading →

We recently had a client that had a need for hosting and streaming videos from their website. These videos were public domain videos, some found on YouTube, NASA’s website, and other resources, and the client was concerned that the videos might be taken down or moved, so they were insistent on hosting the videos on their site. There was also a desire to not require users to have to install Windows Media Player, Quick Time, Flash to be able to view all videos.

Continue Reading →

Magic quotes can be the bane of any PHP programmer’s existence. The feature is intended to be helpful and ward off possible SQL injections, but when you’re developing open-source applications, you never know who’s going to have it on. So do you code for magic quotes or not? All politics aside, I’m going to say not. But it is possible to cater to servers with it both on and off.

Continue Reading →