* vicb/cfg_rebase:
[Config] Ability to add and override node types without having to subclass NodeBuilder
[DoctrineBundle] Fix some typos
[SwiftMailerBundle] Fix a merge issue in the configuration
Tweak PHPDocs in the extension configuration files
[Config] Component refactoring
The onCore* events are fired at some pre-defined points during the
handling of a request. At this is more important than the fact
that you can change things from the event.
The Config component API have changed and the extension configuration files must be updated accordingly:
1. Array nodes must enclosed their children definition in ->children() ... ->end() calls:
Before:
$treeBuilder->root('zend', 'array')
->arrayNode('logger')
->scalarNode('priority')->defaultValue('INFO')->end()
->booleanNode('log_errors')->defaultFalse()->end()
->end();
After:
$treeBuilder->root('zend', 'array')
->children()
->arrayNode('logger')
->children()
->scalarNode('priority')->defaultValue('INFO')->end()
->booleanNode('log_errors')->defaultFalse()->end()
->end()
->end()
->end();
2. The 'builder' method (in NodeBuilder) has been dropped in favor of an 'append' method (in ArrayNodeDefinition)
Before:
$treeBuilder->root('doctrine', 'array')
->arrayNode('dbal')
->builder($this->getDbalConnectionsNode())
->end();
After:
$treeBuilder->root('doctrine', 'array')
->children()
->arrayNode('dbal')
->append($this->getDbalConnectionsNode())
->end()
->end();
3. The root of a TreeBuilder is now an NodeDefinition (and most probably an ArrayNodeDefinition):
Before:
$root = $treeBuilder->root('doctrine', 'array');
$this->addDbalSection($root);
public function addDbalSection(NodeBuilder $node)
{
...
}
After:
$root = $treeBuilder->root('doctrine', 'array');
$this->addDbalSection($root);
public function addDbalSection(ArrayNodeDefinition $node)
{
...
}
4. The NodeBuilder API has changed (this is seldom used):
Before:
$node = new NodeBuilder('connections', 'array');
After:
The recommended way is to use a tree builder:
$treeBuilder = new TreeBuilder();
$node = $treeBuilder->root('connections', 'array');
An other way would be:
$builder = new NodeBuilder();
$node = $builder->node('connections', 'array');
Some notes:
- Tree root nodes should most always be array nodes, so this as been made the default:
$treeBuilder->root('doctrine', 'array') is equivalent to $treeBuilder->root('doctrine')
- There could be more than one ->children() ... ->end() sections. This could help with the readability:
$treeBuilder->root('doctrine')
->children()
->scalarNode('default_connection')->end()
->end()
->fixXmlConfig('type')
->children()
->arrayNode('types')
....
->end()
->end()
This is mirrored off of the messages used by git flow and serves to give the user some initial direction (and to avoid "forgetting" the setup steps).
I realize that I've hardcoded documentation URLs into this task, but I think the benefit outweighs the cost of needing to make sure these are always up-to-date.
This command uses a new container pass which dumps the ContainerBuilder into a cache file by serializing it. It's possible that we don't want this to run when kernel.debug = false, but I don't see the harm of generating the file and running the container:debug in, for example, the prod environment seems to make sense.
* kriswallsmith/framework/optimize-debug-dispatcher:
[FrameworkBundle] optimized the debug event dispatcher to avoid instantiating every listener every time
The only missing part is ContainerAwareEventManager::addEventSubscriberService(),
because I'm not sure how to find out the class name of a service in the DIC.
Also, inline documentation of this code needs to be finished once it is accepted.
Doctrine's EventManager implementation has several advantages over the
EventDispatcher implementation of Symfony2. Therefore I suggest that we
use their implementation.
Advantages:
* Event Listeners are objects, not callbacks. These objects have handler
methods that have the same name as the event. This helps a lot when
reading the code and makes the code for adding an event listener shorter.
* You can create Event Subscribers, which are event listeners with an
additional getSubscribedEvents() method. The benefit here is that the
code that registers the subscriber doesn't need to know about its
implementation.
* All events are defined in static Events classes, so users of IDEs benefit
of code completion
* The communication between the dispatching class of an event and all
listeners is done through a subclass of EventArgs. This subclass can be
tailored to the type of event. A constructor, setters and getters can be
implemented that verify the validity of the data set into the object.
See examples below.
* Because each event type corresponds to an EventArgs implementation,
developers of event listeners can look up the available EventArgs methods
and benefit of code completion.
* EventArgs::stopPropagation() is more flexible and (IMO) clearer to use
than notifyUntil(). Also, it is a concept that is also used in other
event implementations
Before:
class EventListener
{
public function handle(EventInterface $event, $data) { ... }
}
$dispatcher->connect('core.request', array($listener, 'handle'));
$dispatcher->notify('core.request', new Event(...));
After (with listeners):
final class Events
{
const onCoreRequest = 'onCoreRequest';
}
class EventListener
{
public function onCoreRequest(RequestEventArgs $eventArgs) { ... }
}
$evm->addEventListener(Events::onCoreRequest, $listener);
$evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
After (with subscribers):
class EventSubscriber
{
public function onCoreRequest(RequestEventArgs $eventArgs) { ... }
public function getSubscribedEvents()
{
return Events::onCoreRequest;
}
}
$evm->addEventSubscriber($subscriber);
$evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
The Response is not available in the DIC anymore.
When you need to create a response, create an instance of
Symfony\Component\HttpFoundation\Response instead.
As a side effect, the Controller::createResponse() and Controller::redirect()
methods have been removed and can easily be replaced as follows:
return $this->createResponse('content', 200, array('foo' => 'bar'));
return new Response('content', 200, array('foo' => 'bar'));
return $this->redirect($url);
return Response::createRedirect($url);
Without this patch, if you call __toString() on a Response,
the content-type auto-detection would never be trigerred
as __toString() changes the default content-type.
* weaverryan/config_definition_changes:
[SecurityBundle] Allowing the main Configuration tree to allow "factories" without a validation exception.
[SecurityBundle] Removing an old configuration key in a test - caught by the Configuration validation.
[SecurityBundle] Adding the ignoreExtraFields option to the factories tree so that there aren't validation errors on all the other unknown fields.
[Config] Adding an ignoreExtraKeys options, which allows you to let options simply be ignore without throwing a validation exception.
[Config] Reverting some meaningless changes that are no longer needed to minimize the true diff of the changes. Increasing the test precision.
[Config] Reverting the preventExtraKeys option. This is a revert of functionality that would have allowed "unnamed" children to be added to an array node.
[Config] Moving the removal of the key attribute on ArrayNode onto the setKeyAttribute() method per Johannes.
[Config] Renaming the key attribute removal property for consistency per Johannes' recommendation. Also fixing a PHPDoc typo per Stof.
[SwiftmailerBundle] Removing unnecessary "enabled" key in a test.
[FrameworkBundle] Removing the "namespace" key when it's defined in its own weird location in XML. This prevents that key, which we move in this same location, from looking like an invalid option during validation.
[Config] Renaming NodeBuilder::nodeBuilder() to NodeBuilder::builder() due to the fact that PHP can get confused when you have a __construct() method *and* a method that has the same name as the class (looks like two constructors to PHP).
[Config] Making the option to remove a key attribute optional.
[Config] Renaming the NodeBuilder::addNodeBuilder() to simply NodeBuilder::nodeBuilder() to be consistent with the other names: node(), arrayNode().
[Config] Making changes per the recent movement of the Config builder into the Config component.
[DependencyInjection] Renaming allowUnnamedChildren to preventExtraKeys. Also moved the place where validation of extra configs occurs.
[DependencyInjection] Being sure to remove XML-remapped singular options and key attribute options after processing.
[DependencyInjection] Adding a NodeBuilder::addNodeBuilder() method that helps achieve a fluid interface when a pre-built NodeBuilder needs to be added.
[DependencyInjection] Initial implementation of an allowUnnamedChildren method on NodeBuilder. Also added an "extra field" exception.
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
* Added the --format parameter to the InitBundleCommand.php file
* Moved all the non-format-dependent files from Resources/skeleton/bundle to Resources/skeleton/bundle/generic
* Created Resources/skeleton/bundle/[php,yml,xml] subfolders containing the files config/routing.[xml,yml,php]
* Remove redundant null/true equivalent array() values for array nodes
* Profiler matcher should not be deep merged; subsequent configs can simply overwrite its array
* Per lsmith's suggestion, change "isset(x) && x" to "!empty(x)"
* Templating engines node should be required, which is necessary to ensure requiresAtLeastOneElement() applies to its prototype children
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.
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.
This fixes some BC problems introduced in f9138d313b. Some top-level can now be simply enabled by providing true/null in PHP/YAML. Additionally, the Configuration\Builder allows options to be unset by providing "false" (helpful for overriding activation in a previous config file). All options supporting these behaviors can be found in the Configuration.php file (look for canBeUnset() and treatNull/TrueLike()).
Major changes:
* Removed "enabled" option for profiler config. Profiler is now enabled if its config is true, null or a map.
* Restore original config structure for validation namespaces. In PHP/YAML, namespaces are defined under annotations as an alternative to false (disabled) and true/null (enabled). For XML, annotation remains a boolean attribute for validation and a one or more optional namespace tags may appear within <app:validation />. During config normalization, namespace tags under validation will be moved to annotations to conform to the PHP/YAML structure (this occurs transparently to the user).
* Restore behavior for router/templating config sections being optional (as shown in changes to session/validation test fixtures). If either top-level section is unset in the configuration, neither feature will be enabled and the user will no longer receive exceptions due to missing a resource option (router) or engines (templating). Resource/engines will still be properly required if the respective feature is enabled.
* Remove unused router type option from XML config XSD. Type is only relevant for import statements, so this option is likely useless.
Additional small changes:
* Added isset()'s, since config options may be unset
* Wrap registerXxxConfiguration() calls in isset() checks
* Load translation.xml in configLoad(), since it's always required
* Default cache_warmer value (!kernel.debug) is determined via Configuration class
Things to be fixed:
* Configuration\Builder doesn't seem to respect isRequired() and requiresAtLeastOneElement() (or I haven't set it properly); this should replace the need for FrameworkExtension to throw exceptions for bad router/templating configs
* The config nodes for session options don't have the "pdo." prefix, as dots are not allowed in node names. To preserve BC for now, the "pdo." prefix is still allowed (and mandated by XSD) in configuration files. In the future, we may just want to do away with the "pdo." prefix.
* Translator has an "enabled" option. If there's no use case for setting "fallback" independently (when "enabled" is false), perhaps "enabled" should be removed entirely and translator should function like profiler currently does.
* Profiler matcher merging might need to be adjusted so multiple configs simply overwrite matcher instead of merging its array keys.
Restructured config format to make processing more straightforward. Important changes that might break existing configs:
* Added "enabled" option for translator (improves multi-format compat)
* Removed hash variation of validation annotations option (only boolean)
* Moved namespace option directly under validation (improves multi-format compat)
The new merge process depends on an internal array of all supported options and their default values, which is used for both validating the config schema and inferring how to merge options (as an added benefit, it helps make the extension self-documenting). Exceptions will now be thrown for merge errors resulting from unrecognized options or invalid types. Since incoming configurations are all merged atop the defaults, many isset() checks were removed. As a rule of thumb, we probably only want to ignore null values when an option would be used to set a parameter.
Also:
* Added missing attributes to symfony-1.0.xsd
* profiler: added only-exceptions attribute
* session: fix types and add pdo attributes
* Create FrameworkExtension tests with PHP/XML/YAML fixtures
* Use "%" syntax instead of calling getParameter() within FrameworkExtension
* Normalize config keys and arrays with helper methods for PHP/XML/YAML compatibility
Earlier changes:
* Remove nonexistent "DependencyInjection/Resources/" path from XmlFileLoaders
* Remove hasDefinition() checks, as register methods should only execute once
* Remove first-run logic from registerTranslatorConfiguration(), as it is only run once
* Removed apparently obsolete clearTags() calls on definitions for non-enabled features
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 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
}
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.
You must now explicitly register the templating engine you want to use:
<app:templating>
<app:engine id="twig" />
</app:templating>
app.templating:
engines: ['twig']
Symfony2 comes with two such engines: 'twig', and 'php'.
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" />
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.
Before
bundle:section:template.format.renderer
After
bundle:section:template.renderer.format
Notice that both the renderer and the format are mandatory.
* 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
The SecurityFactories expect security services to have a consistent naming convention, which was not the case for providers defined as `{ id: another.service }`. These providers will now be aliased as "security.authentication.provider.[key]" and can be accessed in the same manner as other providers.
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, ...
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
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.
