Note that this commit removes the built-in support for MongoDB user providers.
This code can be moved back in once there is a stable release for MongoDB, but
for now you have to set-up that user provider just like you would set-up any
custom user provider:
security:
providers:
document_provider:
id: my.mongo.provider
How to upgrade?
For XML configuration files:
* All extensions should now use the config tag (this is just a convention as
the YAML configurations files do not use it anymore):
* The previous change means that the doctrine and security bundles now are
wrapped under a main "config" tag:
<doctrine:config>
<doctrine:orm />
<doctrine:dbal />
</doctrine:config>
<security:config>
<security:acl />
...
</security:config>
For YAML configuration files:
* The main keys have been renamed as follows:
* assetic:config -> assetic
* app:config -> framework
* webprofiler:config -> web_profiler
* doctrine_odm.mongodb -> doctrine_mongo_db
* doctrine:orm -> doctrine: { orm: ... }
* doctrine:dbal -> doctrine: { dbal: ... }
* security:config -> security
* security:acl -> security: { acl: ... }
* twig.config -> twig
* zend.config -> zend
This allows for better conventions and better error messages if you
use the wrong configuration alias in a config file.
This is also the first step for a bigger refactoring of how the configuration
works (see next commits).
* Bundle::registerExtensions() method has been renamed to Bundle::build()
* The "main" DIC extension must be renamed to the new convention to be
automatically registered:
SensioBlogBundle -> DependencyInjection\SensioBlogExtension
* The main DIC extension alias must follow the convention:
sensio_blog for SensioBlogBundle
* If you have more than one extension for a bundle (which should really
never be the case), they must be registered manually by overriding the
build() method
* If you use YAML or PHP for your configuration, renamed the following
configuration entry points in your configs:
app -> framework
webprofiler -> web_profiler
doctrine_odm -> doctrine_mongo_db
In routing files, import statements allow an optional "type" option to hint the resources' type (e.g. for ambiguous file extensions). This adds the same type option to the FrameworkExtension config, which defines the main routing resource.
XML/YAML loaders assume imported resources are files before attempting to resolve their loader. This is problematic for loaders such as Assetic, which does not use a file as its resource. Furthermore, the previous consecutive calls to both locate() and getAbsolutePath() were redundant. File location can safely be delayed until FileLoader::import(), and we can let that throw an exception if the file is not found.
This reverts commit f53080860a.
Revert "[Router] config fixes"
This reverts commit 51beecc6f2.
Revert "moved duplicated files to a new Config component"
This reverts commit a8ec9b27f0.
Rules are :
- If one of the ESI has validation cache strategy, the whole page will be
forced to validate.
- In none of the ESI has validation, the response will feature a Cache-Control
directive with s-maxage value equals to the smallest TTL of ESIs.
The merging is done in three steps:
1. Normalization:
=================
All passed config arrays will be transformed into the same structure
regardless of what format they come from.
2. Merging:
===========
This is the step when the actual merging is performed. Starting at the root
the configs will be passed along the tree until a node has no children, or
the merging of sub-paths of the current node has been specifically disabled.
Left-Side Right-Side Merge Result
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-nothing- array Right-Side will be taken.
scalar scalar Right-Side will be taken.
array false Right-Side will be taken if ->canBeUnset()
was called on the array node.
false array Right-Side will be taken.
array array Each value in the array will be passed to
the specific child node, or the prototype
node (whatever is present).
3. Finalization:
================
The normalized, and merged config will be passed through the config tree to
perform final validation on the submitted values, and set default values
where this has been requested.
You can influence this process in various ways, here is a list with some examples.
All of these methods must be called on the node on which they should be applied.
* isRequired(): Node must be present in at least one config file.
* requiresAtLeastOneElement(): PrototypeNode must have at least one element.
* treatNullLike($value): Replaces null with $value during normalization.
* treatTrueLike($value): Same as above just for true
* treatFalseLike($value): Same as above just for false
* defaultValue($value): Sets a default value for this node (only for scalars)
* addDefaultsIfNotSet(): Whether to add default values of an array which has not
been defined in any configuration file.
* disallowNewKeysInSubsequentConfigs(): All keys for this array must be defined
in one configuration file, subsequent
configurations may only overwrite these.
* fixXmlConfig($key, $plural = null): Transforms XML config into same structure
as YAML, and PHP configurations.
* useAttributeAsKey($name): Defines which XML attribute to use as array key.
* cannotBeOverwritten(): Declares a certain sub-path as non-overwritable. All
configuration for this path must be defined in the same
configuration file.
* cannotBeEmpty(): If value is set, it must be non-empty.
* canBeUnset(): If array values should be unset if false is specified.
Architecture:
=============
The configuration consists basically out of two different sets of classes.
1. Builder classes: These classes provide the fluent interface and
are used to construct the config tree.
2. Node classes: These classes contain the actual logic for normalization,
merging, and finalizing configurations.
After you have added all the metadata to your builders, the call to
->buildTree() will convert this metadata to actual node classes. Most of the
time, you will not have to interact with the config nodes directly, but will
delegate this to the Processor class which will call the respective methods
on the config node classes.
This commit removes CollectionToStringTransformer. Transformers should never change the state of the outside world, otherwise hard-to-track bugs might creap in.
This functionality needs to be implemented as a custom FieldType (see EntityChoiceField).
The implication is that set<Reference>() in the object of the parent form will not be called (and thus not has to be implemented/public).
If you want to suppress this behaviour, manually set "by_reference" to false.
Previously, the Definition class was used both for type inference and factory construction (if factoryService was absent). This is fine for cases where classes create instances of themselves (e.g. getInstance() or create()), but leads to ambiguity when we have a separate factory class.
Separated validation of data and form had serious drawbacks. When a form had nested form whose data was not connected to the data of the root form, this data would not be validated.
The new implementation validates the whole object graph at once. Class Form has a new method validateData(), that manually passes the data to the GraphWalker of the Validator and overrides the Default group with the groups set in the form.
This is mainly intended for complex configurations to ease the work you
have with normalizing different configuration formats (YAML, XML, and PHP).
First, you have to set-up a config tree:
$treeBuilder = new TreeBuilder();
$tree = $treeBuilder
->root('security_config', 'array')
->node('access_denied_url', 'scalar')->end()
->normalize('encoder')
->node('encoders', 'array')
->key('class')
->prototype('array')
->before()->ifString()->then(function($v) { return array('algorithm' => $v); })->end()
->node('algorithm', 'scalar')->end()
->node('encode_as_base64', 'scalar')->end()
->node('iterations', 'scalar')->end()
->end()
->end()
->end()
->buildTree()
;
This tree and the metadata attached to the different nodes is then used
to intelligently transform the passed config array:
$normalizedConfig = $tree->normalize($config);
With the form factory there was no reasonable way to implement instantiation of custom form classes. So the implementation was changed to let the classes instantiate themselves. A FormContext instance with default settings has to be passed to the creation method. This context is by default configured in the DI container.
$context = $this->get('form.context');
// or
$context = FormContext::buildDefault();
$form = MyFormClass::create($context, 'author');
If you want to circumvent this process, you can also create a form manually. Remember that the services stored in the default context won't be available then unless you pass them explicitely.
$form = new MyFormClass('author');
A form now always has to be bound, independent of whether the request is a POST request or not. The bind() method detects itself whether the request was a post request or not and reads its data accordingly. The "old" bind()/isBound() methods were renamed to submit()/isSubmitted().
$form = new Form('author');
$form->bind($request, $author);
if ($form->isValid()) {
// isValid() implies isSubmitted(), non-submitted forms can
// never be valid
// do something with author now
}
Alternatively, you can only bind global variables, if you don't have a request object.
$form->bindGlobals($author);
Note that the $author object is in both cases optional. You can also pass no object at all and read the data using $form->getData(), but then no validation will occur. You can also prefill the form with an object during instantiation.
$form = new Form('author', array('data' => $author));
$form->bind($request);
// etc.
The Request constructor no longer uses values from PHP's super globals. If you want a Request populated with these values you must use the new static method Request::fromGlobals().
Your front controllers (i.e. web/app.php, web/app_dev.php ...) will need to be updated:
// old
$kernel->handle(new Request())->send();
// new
$kernel->handle(Request::fromGlobals())->send();
A class in Symfony2 can be loaded by four different mechanisms:
* bootstrap.php: This file contains classes that are always required and
needed very early in the request handling;
* classes.php: This file contains classes that are always required and
managed by extensions via addClassesToCompile();
* MapFileClassLoader: This autoloader uses a map of class/file to load
classes (classes are managed by extensions via addClassesToAutoloadMap(),
and should contain often used classes);
* UniversalAutolaoder: This autoloader loads all other classes (it's the
slowest one).
The three notification methods do not return the Event instance anymore.
notify() does not return anything
notifyUntil() returns the returned value of the event that has processed the event
filter() returns the filtered value
Upgrading your listeners:
Listeners for notify() and filter() events: nothing to change
Listeners for notifyUntil() events:
Before:
$event->setReturnValue('foo');
return true;
After:
$event->setProcessed();
return 'foo';
If you notify events, the processing also need to be changed:
For filter() notifications: the filtered value is now available as
the returned value of the filter() method.
For notifyUntil() notifications:
Before:
$event = $dispatcher->notifyUntil($event);
if ($event->isProcessed()) {
$ret = $event->getReturnValue();
// do something with $ret
}
After:
$ret = $dispatcher->notifyUntil($event);
if ($event->isProcessed()) {
// do something with $ret
}
* Added empty_value option on CountryField, LanguageField, LocaleField, TimezoneField
* Added missing date_pattern to DateTimeField
* Made the currency option on MoneyField required.
To benefit from the optimization, you need to change this line from your
autoload.php:
require_once $vendorDir.'/symfony/src/Symfony/Component/HttpFoundation/UniversalClassLoader.php';
to this one:
require_once $vendorDir.'/symfony/src/Symfony/Component/HttpKernel/bootstrap.php';
Notice that if you don't do this change, your app will in fact be slower than before.
Cache warmer will come in the next commits.
To warm up the cache on a production server, you can use
the cache:warmup command:
./app/console_prod cache:warmup
* The register() method on all listeners has been removed
* Instead, the information is now put directly in the DIC tag
For instance, a listener on core.request had this method:
public function register(EventDispatcher $dispatcher, $priority = 0)
{
$dispatcher->connect('core.response', array($this, 'filter'), $priority);
}
And this tag in the DIC configuration:
<tag name="kernel.listener" />
Now, it only has the following configuration:
<tag name="kernel.listener" event="core.response" method="filter" priority="0" />
The event and method attributes are now mandatory.
I believe the empty_value option is just a leftover Django-style option for what value the field should have if left blank. I don't see this doing anything and find no reference to anything like it anywhere else.
The separator option functionality is currently handled as a parameter in the field render functions. I think this should be moved to an option on the field, but this reflects teh current functionality (i.e. this option is not used).
This adds lazy loading for firewall configurations. This is useful when you have multiple firewalls, only the firewalls which are actually needed to process the Request are initialized. So, your event dispatcher is not as costly to initialize anymore.
It also implements re-using of RequestMatchers if all matching rules are the same, and exposes the remaining rules which are already implemented by the request matcher (host, ip, methods) in the access-control section
Before I explain the changes, let's talk about the current state.
Before this patch, the registerBundleDirs() method returned an ordered (for
resource overloading) list of namespace prefixes and the path to their
location. Here are some problems with this approach:
* The paths set by this method and the paths configured for the autoloader
can be disconnected (leading to unexpected behaviors);
* A bundle outside these paths worked, but unexpected behavior can occur;
* Choosing a bundle namespace was limited to the registered namespace
prefixes, and their number should stay low enough (for performance reasons)
-- moreover the current Bundle\ and Application\ top namespaces does not
respect the standard rules for namespaces (first segment should be the
vendor name);
* Developers must understand the concept of "namespace prefixes" to
understand the overloading mechanism, which is one more thing to learn,
which is Symfony specific;
* Each time you want to get a resource that can be overloaded (a template for
instance), Symfony would have tried all namespace prefixes one after the
other until if finds a matching file. But that can be computed in advance
to reduce the overhead.
Another topic which was not really well addressed is how you can reference a
file/resource from a bundle (and take into account the possibility of
overloading). For instance, in the routing, you can import a file from a
bundle like this:
<import resource="FrameworkBundle/Resources/config/internal.xml" />
Again, this works only because we have a limited number of possible namespace
prefixes.
This patch addresses these problems and some more.
First, the registerBundleDirs() method has been removed. It means that you are
now free to use any namespace for your bundles. No need to have specific
prefixes anymore. You are also free to store them anywhere, in as many
directories as you want. You just need to be sure that they are autoloaded
correctly.
The bundle "name" is now always the short name of the bundle class (like
FrameworkBundle or SensioCasBundle). As the best practice is to prefix the
bundle name with the vendor name, it's up to the vendor to ensure that each
bundle name is unique. I insist that a bundle name must be unique. This was
the opposite before as two bundles with the same name was how Symfony2 found
inheritance.
A new getParent() method has been added to BundleInterface. It returns the
bundle name that the bundle overrides (this is optional of course). That way,
there is no ordering problem anymore as the inheritance tree is explicitely
defined by the bundle themselves.
So, with this system, we can easily have an inheritance tree like the
following:
FooBundle < MyFooBundle < MyCustomFooBundle
MyCustomFooBundle returns MyFooBundle for the getParent() method, and
MyFooBundle returns FooBundle.
If two bundles override the same bundle, an exception is thrown.
Based on the bundle name, you can now reference any resource with this
notation:
@FooBundle/Resources/config/routing.xml
@FooBundle/Controller/FooController.php
This notation is the input of the Kernel::locateResource() method, which
returns the location of the file (and of course it takes into account
overloading).
So, in the routing, you can now use the following:
<import resource="@FrameworkBundle/Resources/config/internal.xml" />
The template loading mechanism also use this method under the hood.
As a bonus, all the code that converts from internal notations to file names
(controller names: ControllerNameParser, template names: TemplateNameParser,
resource paths, ...) is now contained in several well-defined classes. The
same goes for the code that look for templates (TemplateLocator), routing
files (FileLocator), ...
As a side note, it is really easy to also support multiple-inheritance for a
bundle (for instance if a bundle returns an array of bundle names it extends).
However, this is not implemented in this patch as I'm not sure we want to
support that.
How to upgrade:
* Each bundle must now implement two new mandatory methods: getPath() and
getNamespace(), and optionally the getParent() method if the bundle extends
another one. Here is a common implementation for these methods:
/**
* {@inheritdoc}
*/
public function getParent()
{
return 'MyFrameworkBundle';
}
/**
* {@inheritdoc}
*/
public function getNamespace()
{
return __NAMESPACE__;
}
/**
* {@inheritdoc}
*/
public function getPath()
{
return strtr(__DIR__, '\\', '/');
}
* The registerBundleDirs() can be removed from your Kernel class;
* If your code relies on getBundleDirs() or the kernel.bundle_dirs parameter,
it should be upgraded to use the new interface (see Doctrine commands for
many example of such a change);
* When referencing a bundle, you must now always use its name (no more \ or /
in bundle names) -- this transition was already done for most things
before, and now applies to the routing as well;
* Imports in routing files must be changed:
Before: <import resource="Sensio/CasBundle/Resources/config/internal.xml" />
After: <import resource="@SensioCasBundle/Resources/config/internal.xml" />
Now that we have a compilation phase for the DIC, using tags after compilation
is not needed anymore.
Tags were introduced to allow several independant bundles to be able to
interact which each others (remember that each extension knows nothing about
the others).
But during the compilation phase, the container has been merged ans so, all
the information from all bundles are available. This is then the right place
to deal with tags. That way, less work is needed at runtime and the DIC class
in the cache is also much smaller.
For simple cases, it means that you need to process the tag in a compiler pass
and store the information you need in a DIC parameter (have a look at the
TranslatorPass for a very simple example).
So, the PHP dumper does not add tags to the dumped PHP class anymore (it does
not implements TaggedContainerInterface anymore). But tags are still available
on ContainerBuilder instances.
Let's take some examples to explain the change.
First, if you don't use any vendored bundles, this commit does not change anything.
So, let's say you use a FooBundle from Sensio. The files are stored under Bundle\Sensio\FooBundle.
And the Bundle class is Bundle\Sensio\FooBundle\SensioFooBundle.php.
Before the change, the bundle name ($bundle->getName()) would have returned 'FooBundle'.
Now it returns 'SensioFooBundle'.
Why does it matter? Well, it makes template names and controller names easier to read:
Before:
Template: Sensio\FooBundle:Bar:index.twig.html
Controller: Sensio\FooBundle:Bar:indexAction
After
Template: SensioFooBundle:Bar:index.twig.html
Controller: SensioFooBundle:Bar:indexAction
NB: Even if the change seems simple enough, the implementation is not. As finding
the namespace from the bundle class name is not trivial
NB2: If you don't follow the bundle name best practices, this will probably
leads to unexpected behaviors.
* better separation of concerns
* made TwigBundle independant of the PHP Engine from FrameworkBundle (WIP)
* removed one layer of abstraction in the Templating component (renderers)
* made it easier to create a new Engine for any templating library
* made engines lazy-loaded (PHP engine for instance is not started if you only use Twig)
* reduces memory footprint (if you only use one engine)
* reduces size of compiled classes.php cache file
* made the renderer argument of Storage ctor mandatory
* refactored the Engine class to avoid code duplication
* simplified the check for a template that extends another one but with a different renderer
- inline private services which are references multiple times, but where all references originate from the same definition
- bug fix for non-shared services which were considered shared within the scope in which they were inlined
The current `loadClass()` implementation tries to load a class from the first matching prefix then stops, producing false-negative results. This is especially evident in groups of related libraries, such as Doctrine:
Doctrine
Doctrine\Common
Doctrine\Common\DataFixtures
Doctrine\DBAL
Doctrine\DBAL\Migrations
Each of these libraries is submoduled into a different vendor directory. Depending on what order these libraries are added to a UniversalClassLoader instance, classes may or may not actually be loaded. This fix continues searching registered namespaces and prefixes if the first partial match is negative.
These helpers have been removed as they do not work as expected.
Among other things, the order is not the right one when using PHP
templates, and adding assets from an included template is not
possible when using Twig templates.
This should be replaced by integrating a third-party library that
manages assets: minification, compilation, packaging, ...
If a user was not authenticated and visited the logout path, a null value was passed to the handler's logout() method, resulting in a catchable fatal error.
If the option is true, the password is never written into the input field's value. If it is false, it is only written into the input field's value after submitting a form with errors.
The default value for "always_empty" is true.
The semantics of property paths are now:
(1) if a property path is set, it is _always_ respected (relative to the object
of the parent field)
(2) if no property path is set, the object of the parent field is _always_ ignored
Fact (2) allows us to set data into fields that is updated independently of the parent
field (like CSRF tokens, subforms with different objects etc.)
What is missing now is support for subfields that pass the object of the parent field
through to their own subfields. This functionality would be needed for GoogleMapFields,
DateRangeFields etc., which are compositions of individual fields that update the
parent object of the FieldGroup.
There are several alternatives for the latter functionality that should be discussed
in a RFC.
Original explanation from pull request:
I'm Using symfony2 with URL Rewriting to 'hide' index.php.
On form authentication, symfony2 redirect to http://host:port/index.php/login_path instead of http://host:port/login_path. I do understand that, in my case, redirect is set into one of :
FormAuthenticationEntryPoint with getUriForPath()
FormAuthenticationListener with getUriForPath()
Security/Firewal/ExceptionListener with getUri()
This path modify getUri and getUriForPath to :
remove default port from URI
remove script name if not initially present
- interfaces can now also be defined on containers which are built with an Extension
- interface injection can also be used on classes that require constructor arguments
Currently, ambiguities only arise for PHP files, as PhpFileLoader and AnnotationFileLoader would both claim support. Future conflicts may occur if the XML, YAML, or PHP loaders were to receive Directory and Glob loaders (as annotations have).
Since the "type" parameter is optional, loader resolution will default to awarding resolution to the first loader to claim support. A previous hack in PhpFileLoader to avoid an AnnotationFileLoader conflict was removed, so that should be the only lost backwards compatibility with this patch. Unit tests were also created for the various loader classes, although only the supports() method is being tested.
This implementation was proposed on the symfony-dev mailing list in response to Fabien's RFC for custom loader notation: http://groups.google.com/group/symfony-devs/browse_thread/thread/3104c1a9e45799d2/20fbe393c1afe088
Both HttpKernel and Security define a 403 exception:
* Symfony\Component\HttpKernel\Exception\ForbiddenHttpException
* Symfony\Component\Security\Exception\AccessDeniedException
The one in HttpKernel has been removed in favor of the Security one.
Previously, HttpKernel performed request-stashing. By moving this to the Kernel class, the request is now available immediately after the kernel becomes aware of it. If the kernel is allowed to boot lazily (during the first call to handle()), this also allows an actual master Request to be available during booting.
The old "request" service definition (with a bogus class name) can be replaced with a factory-aware definition that retrieves the request directly from the kernel.
The original HttpKernel class can be deleted, as it's request-stashing will be moved to the Kernel class. FrameworkBundle's list of compiled classes must also be modified to respect this change.
To keep language consistent, three methods were changed in InputOption:
* `InputOption::acceptParameter()` -> `InputOption::acceptValue()`
* `InputOption::isParameterRequired()` -> InputOption::isValueRequired()`
* `InputOption::isParameterOptional()` -> `InputOption::isValueOptional()`
The InputDefinition::asXml() method was also modified to update the `accept_value` and `is_value_required` attributes.
When an object has a "main" many relation with related "things" (objects,
parameters, ...), the method names are normalized:
* get()
* set()
* all()
* replace()
* remove()
* clear()
* isEmpty()
* add()
* register()
* count()
* keys()
The classes below follow this method naming convention:
* BrowserKit\CookieJar -> Cookie
* BrowserKit\History -> Request
* Console\Application -> Command
* Console\Application\Helper\HelperSet -> HelperInterface
* DependencyInjection\Container -> services
* DependencyInjection\ContainerBuilder -> services
* DependencyInjection\ParameterBag\ParameterBag -> parameters
* DependencyInjection\ParameterBag\FrozenParameterBag -> parameters
* DomCrawler\Form -> FormField
* EventDispatcher\Event -> parameters
* Form\FieldGroup -> Field
* HttpFoundation\HeaderBag -> headers
* HttpFoundation\ParameterBag -> parameters
* HttpFoundation\Session -> attributes
* HttpKernel\Profiler\Profiler -> DataCollectorInterface
* Routing\RouteCollection -> Route
* Security\Authentication\AuthenticationProviderManager -> AuthenticationProviderInterface
* Templating\Engine -> HelperInterface
* Translation\MessageCatalogue -> messages
The usage of these methods are only allowed when it is clear that there is a
main relation:
* a CookieJar has many Cookies;
* a Container has many services and many parameters (as services is the main
relation, we use the naming convention for this relation);
* a Console Input has many arguments and many options. There is no "main"
relation, and so the naming convention does not apply.
For many relations where the convention does not apply, the following methods
must be used instead (where XXX is the name of the related thing):
* get() -> getXXX()
* set() -> setXXX()
* all() -> getXXXs()
* replace() -> setXXXs()
* remove() -> removeXXX()
* clear() -> clearXXX()
* isEmpty() -> isEmptyXXX()
* add() -> addXXX()
* register() -> registerXXX()
* count() -> countXXX()
* keys()
* removed the __call() method in Container: it means that now, there is only
one way to get a service: via the get() method;
* removed the $shared variable in the dumped Container classes (we now use
the $services variable from the parent class directly -- this is where we
have a performance improvement);
* optimized the PHP Dumper output.
This is the case for instance when you pass a variable to a template like this:
new SafeDecorator($var);
and in the template, you pass it again to another embedded template:
$view->render('...', array('var' => $var);
The second time, $var will be escaped as the SafeDecorator wrapper will have been removed
by the escaper.
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.
Added ability to specify **match-all** validation group, which
constraints will runs on every specified validation group.
Added groups="*" option to `Form::data` Valid validator.
In the dumped PHP class, we must use get() and not get*Service() methods to get services.
That's because all calls must be managed by get(). From the outside, you can call
get*Service() because as they are protected, they are caught by the __call() method;
which is not the case obviously when it is used internally.
If not, if you override a service with set(), this won't work when a service
depends on this one (the default one will still be used).
Some explanations on how it works now:
* The Session is an optional dependency of the Request. If you create the
Request yourself (which is mandatory now in the front controller) and if
you don't inject a Session yourself (which is recommended if you want the
session to be configured via dependency injection), the Symfony2 Kernel
will associate the Session configured in the Container with the Request
automatically.
* When duplicating a request, the session is shared between the parent and
the child (that's because duplicated requests are sub-requests of the main
one most of the time.) Notice that when you use ::create(), the behavior is
the same as for the constructor; no session is attached to the Request.
* Symfony2 tries hard to not create a session cookie when it is not needed
but a Session object is always available (the cookie is only created when
"something" is stored in the session.)
* Symfony2 only starts a session when:
* A session already exists in the request ($_COOKIE[session_name()] is
defined -- this is done by RequestListener);
* There is something written in the session object (the cookie will be sent
to the Client).
* Notice that reading from the session does not start the session anymore (as
we don't need to start a new session to get the default values, and because
if a session exists, it has already been started by RequestListener.)
Because that's just not possible (have a look at the unit tests to see all possibilities
-- as you will notice, there is no way we can determine the context and whether the
data are already escaped or not).
So, we always escape data, which means that sometimes, we will try to escape already
escaped data. This is not a problem for everything except strings. That's because
strings are not wrapped with an object like everything else (for performance reason).
This means that all escapers must be able to avoid double-escaping (that's the case
for the default escapers as both htmlspecialchars() and htmlentities() have a flag
that does just this).
This is not really a bug or a big issue, but if you need to temporarily empty a routes node, Symfony shouldn't care - it's not an actual validation failure (a routes node still makes sense without an route or import children).
Fields can now easier support different data types in their underlying object.
These datatypes can be normalized to a single datatype using a normalization
transformer. The normalized value can then be transformed to the user's
representation with the value transformer (better name required?).
This fixes a bug in UniversalClassLoader when attempting to autoload class names with leading slashes:
$namespacedClass = "\\Foo\\Bar";
$pearlikeClass = "\\Foo_Bar";
$namespaced = new $namespacedClass();
$pearlike = new $pearlikeClass();
`UniversalClassLoader::loadClass()` was unable to load PEAR-like classes with leading slashes because it found the slash and assumed that the requested class was namespaced. It was unable to load namespaced classes with leading slashes because it would look them up in the autoloader's registered namespaces, and was unable to match '\Foo' to 'Foo'. One (ugly) workaround for the namespaced classes was to register all namespaces twice:
$loader->registerNamespaces(array(
'Foo' => __DIR__ . '/lib',
'\Foo' => __DIR__ . '/lib',
));
But that's not very pretty, nor does it solve the bug with PEAR-like classes. Stripping the leading slash before trying to autoload allows UniversalClassLoader to load both namespaced and PEAR-like classes.
When reading the last bit of a property path mapped to a missing array index, the method would initialize the value to an empty array. This makes sense for cases where readPropertyPath would again be called recursively, but not when the value would be immediately returned (null would be preferable in that case).
For example, we have an object with a property called "options" that's an array of arbitrary key/value pairs. That "options" property (and getOptions()) maps directly to a FieldGroup within the Form for this object. That FieldGroup contains multiple TextFields for a few expected keys in the array. As-is, if those keys were not defined, the default data set for those TextFields could end up being "Array" (string representation of an empty array). If readPropertyPath instead returns null for this case, the default data would be transformed into an empty string.
It's better to be able to fetch all the visible and all the hidden fields separately for display purposes (hidden fields in <ul> tags without an <li> do not validate)
Before:
/**
* @Validation({@DateTime()})
*/
After:
/**
* @validation:DateTime()
*/
The @validation:Validation() construct is not needed anymore (it is still supported
as this is useful when you have several annotations with the same class).
So, the above is equivalent to:
/**
* @validation:Validation({@validation:DateTime()})
*/
ReflectionClass doesn't list properties on stdClass objects (or objects cast
from arrays). This allows these annoymous objects to be used as field data.
Internally, ChoiceField expects both choices and preferred_choices to be a simple array, so I replaced incomplete bits of code that attempted to not modify a possible ArrayObject and instead added type checks in the configure() method (with unit tests for expected exceptions).
Property paths such as fields[group].fields[innerGroup].data were not being resolved correctly, since the second iteration of addError() (based on "group") would attempt to call get('fields') instead of get('innerGroup'). Solution is to remember to bump the propertyPath forward if we're at the fields property
<foo:bar>
<service class="Foo" />
<service class="Bar" />
</foo:bar>
In the foo:bar extension method, you can retrieve the services with:
// always an array of services
$config['_services']