Client-side validation for the new Symfony forms with jQuery

The new Symfony forms are great improvement over the old forms and once you get over the learning curve you can’t imagine life without them. The only problem with them is that they don’t really offer client-side validation (yes, being agnostic when it comes to Javascript libraries is maybe good but come on). There is fortunately a plugin that does client-side validation but it is Prototype-based, and looks a bit clunky.

For those of us using jQuery there was nothing, so we decided to write our own small helper that integrates this jQuery validator with the new forms. It’s nothing fancy, but it does the trick for now, and we may expand it into a full-fledged plugin that does all sorts of crazy things.

Using the helper:

  1. Download and install the jQuery validation plugin.
  2. Download the helper and put it in lib/helper/jQueryValHelper.php
  3. Include the jQueryVal helper.
  4. To enable the helper for a specific form:
    <?php echo jquery_val_form_tag($form, array(‘action’ => url_for(“@register) ))?>

That’s it.

The validator currently supports email, min and max length validation. The only required option is action, the other options you can pass it are:

  1. error_placement: Change where the errors are rendered, for example:
    'error_placement' => 'error.prependTo(element.parent().next())'
  2. error_element: Change the element used to render the errors, default is label.

All other options you pass are added to the form as attributes.

dv madness – Holy Shit Batman!

So a few days ago Daum and I decided to try and “hackathon” our way through one of our symfony projects.

We were developing on our (mt) gs server which is usually a stable box (until Mediatemple’s whole cluster goes down). Things were going fine until our Symfony controller started to hang and not serve any requests. The gs machine is a shared box so we couldn’t do anything invasive to try and diagnose our problems.

We opened a support ticket and then I tried switching the enviroment off “dev” to “test”, things got better for awhile and then promptly began crashing again. The hackathon was looking more like a crashathon so we decided to try and switch development over to our (mt) dv machine.

To try and salvage the day, we used the DNS rollover delay to discuss our living situation Anyway, so we finally had the new DNS set up and the symfony project migrated over to the dv. And this is where the chaos began.

So first problem, everything we symlinked to “httpdocs” return 403 FORBIDEN errors. We figured it must be the symlinks right? We checked httpd.conf and everything was fine. Daum was getting antsy so finally called (mt) support who informed us that they would open a ticket and get back to us. We tried everything we could think of, symlinks in httpdocs, symlinking to httpdocs, symlinks inside the directory. Symlinks were only working for targets INSIDE httpdocs…

After this fracas, Daum stumbled across a KB ticket that described how to configure specific vhosts on a dv. It turns out PLESK places additional httpd.conf files inside the new vhost directory!?

Ok fine, so we edited up the Plesk http conf to enable our symlinks and mess with the directory structure a bit. Now Symfony was vomitting on require() failing – great. Back to httpd.conf and it turns out Plesk enabled Open_Base_Dir restrictions for php inside the vhost to restrict it to only files inside the document root…

WOW – so after something like 3 hours of yelling at support and messing around we finally transitioned a project from our gs machine to our dv. Things learned:

1. You can’t have a local PEAR install of Propel and Symfony with a different version of Propel

2. On dv servers Plesk installs custom http.conf files PER vhost that customizes Apache and PHP behavior – none of these settings are editable from within Plesk.

3. Moving DNS records within Mediatemple takes time – switching the domain from the gs to dv took at least an hour.