Today we ran in to an issue (or more like an unimplemented enhancement request), where we wanted to do conditional validation.

In our use case, we had a checkbox, which is basically an enable/disable switch. We also had three text inputs, parameters to the feature enabled by the checkbox.

In this case, we wanted the validation of the inputs to depend on whether the switch was enabled.

There are a few ways to do this. You could write your own validator specifically for this purpose. You could write a callback validator, that validates the object. Both these approaches have a big drawback. Even though what all we needed was a conditional NotBlank validator, who knows what we might wish to do in the future with it? We wanted to keep the flexibility of the validation component.

It turns out that’s entirely possible, albeit a bit tricky. To illustrate, let’s imagine a petition. Your form is for entering supporters for a petition. Let’s say that you optionally allow the supporter to enter which city they live in, and that you optionally show that city on a public petition page. Something like this POPO:

<?php

class PetitionSupporter
{
  protected $name;

  protected $city;

  protected $is_city_public;

  // Setters, getters etc. are omitted for brevity
}

Now, of course it wouldn’t be much of a petition if you didn’t require names of the supporters. As for the city, like we’ve said, it’s optional. However, it makes no sense to have the city public unless something is entered.

This can be accomplished using the callback validator, getting the graph walker from the execution context, and validating a separate validation group.

<?php

use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\ExecutionContext;

/**
 * @Assert\Callback(methods={"validateCityExistance"})
 */
class PetitionSupporter
{
  /** @Assert\NotBlank */
  protected $name;

  /** @Assert\NotBlank(groups="public_city_group") */
  protected $city;

  /** @Assert\Type(type="bool") */
  protected $is_city_public;

  public function validateCityExistance(ExecutionContext $ec)
  {
    if ($this->is_city_public) 
    {
      $ec->getGraphWalker()->walkReference($this, 'public_city_group', $ec->getPropertyPath(), true);
    }
  }

  // Setters, getters etc. are omitted for brevity
}

This way, the non-grouped assertions are always validated, and the assertions in the public_city_group group are validated if is_city_public is true.

Of course, you can have more complex validation rules, and you could also have multiple conditional groups depending on one or more of the instance variables.

Symfony Serializer, Symfony2 Component, is a PHP library that can serialize custom objects to and from its object-form and whatever custom format you’d want (json or xml for instance), through the help of Normalizer and Encoder classes.

It is a common use-case to present various objects in other formats, the serializer component provides a good way to manage that. Be it returning a json-representation of some class in an ajax-request or an xml-representation in a REST web service, you can have a common ground to rely on in the serializer-component.

Usage

• The job of a Normalizer is to transform an object (a database entity for instance) to a representation in PHP array form.
• The job of an Encoder is to encode a PHP array to a desired format. The component includes a JsonEncoder- and a XmlEncoder-class.
• The Serializer is the glue and logic that manages all this.

Pass in an array of normalizers and an array of format-name/encoder-pairs in the constructor.

use Symfony\Component\Serializer\Serializer,
    Symfony\Component\Serializer\Encoder\JsonEncoder,
    Symfony\Component\Serializer\Encoder\XmlEncoder;

$serializer = new Serializer(array(
    new FooNormalizer,
    new BarNormalizer
  ), array(
    'ajax_json' => new JsonEncoder(),
    'api_xml' => new XmlEncoder()
  ));

The normalizers above can understand and transform Foo and Bar objects.

When you have this, you can get either an xml or a json-representation of the above objects, depending on what format you ask for.

Lets say $foo is a single object instance, while $bars is a collection of entities, and $some_array is just a normal array, which has no need of a normalizer. It will still be json encoded though.

The BarNormalizer class could look something like this

namespace Acme\DemoBundle\Normalizer;

use Symfony\Component\Serializer\Normalizer\SerializerAwareNormalizer;
use Acme\DemoBundle\Entity\Bar;

class BarNormalizer extends SerializerAwareNormalizer
{
  function normalize($object, $format = null)
  {
    return array(
      'name' => $object->getName(), 
    );
  }

  function denormalize($data, $class, $format = null) {}

  function supportsNormalization($data, $format = null)
  {
    return $data instanceof Bar;
  }

  function supportsDenormalization($data, $type, $format = null) 
  {
    return false;
  }
}

It’s interesting to note that due to the $format parameter, you can have multiple serializers for the same class without collision, if you need different representations for different purposes.

Once all of your normalizers and encoders are in place, using the serializer is simple.

$json = $serializer
  ->serialize(array(
    'foo' => $foo,
    'bars' => array_values($bars->toArray()),
    'baz' => $some_array
  ), 'ajax_json');

In conclusion, using the serializer component you get full flexibility to handle serialization in a simple manner, while still retaining a good separation of concerns.

P.S. In certain use cases, you might also be interested in JMSSerializerBundle, which uses annotations to specify how a given class is serialized.

Me, Magnus, Joakim and Tom went to Symfony Day in Cologne. Lots of fun and great sessions. Here’s a set of photos from our trip.