The PHP native cache limiter feature has been disabled as this is now managed
by the HeaderBag class directly instead (see below.)
The HeaderBag class uses the following rules to define a sensible and
convervative default value for the Response 'Cache-Control' header:
* If no cache header is defined ('Cache-Control', 'ETag', 'Last-Modified',
and 'Expires'), 'Cache-Control' is set to 'no-cache';
* If 'Cache-Control' is empty, its value is set to "private, max-age=0,
must-revalidate";
* But if at least one 'Cache-Control' directive is set, and no 'public' or
'private' directives have been explicitely added, Symfony2 adds the
'private' directive automatically (except when 's-maxage' is set.)
So, remember to explicitly add the 'public' directive to 'Cache-Control' when
you want shared caches to store your application resources:
// The Response is private by default
$response->setEtag($etag);
$response->setLastModified($date);
$response->setMaxAge(10);
// Change the Response to be public
$response->setPublic();
// Set cache settings in one call
$response->setCache(array(
'etag' => $etag,
'last_modified' => $date,
'max_age' => 10,
'public' => true,
));
The constraint "Valid" does not accept any options or groups anymore. As per
JSR303 1.0 final, section 3.5.1 "Object graph validation" (page 39),
properties annotated with valid should be cascaded independent of the current
group (i.e. always). Thus the group "*" is not necessary anymore and was
removed from the "Valid" constraint in the Form validation.xml.
Support for theming in PHP templates has been dropped.
True theming should support theme inheritance, e.g. mytheme <- table <- default.
Currently, the Templating component does not support such inheritance. As the
only purpose of the themes so far was to style field groups with tables or
divs, and because automatic rendering of field groups/forms through the render()
method is discouraged and only recommended for rapid prototyping, themes are
dropped for now.
Modified the framework bundle to use validation => Symfony\Component\Validator\Validator defaults.
Enhanced Framework Extension validator configuration to allow to extend this configuration with
user-specified annotations, for example:
validation:
enabled: true
annotations:
namespaces:
myprojectvalidator: MyProject\Validator\
to register @myprojectvalidator:Validator(...)
This allows the translations to be deeply nested arrays that will be flattened, allowing for namespacing of translations easily.
The following:
'key' => array('key2' => array('key3' => 'value'))
Becomes:
'key.key2.key3' => 'value'
This isn't applied to Xliff since it does not make sense within the scope of the XLIFF standard
The idea of a string port is probably semantically wrong, but it actually follows the convention of at least some web servers ($_SERVER['SERVER_PORT'] is actually a string). And since the $port variable is used as a string in getHttpHost(), it's correct to allow the types not to match.