* 2.0:
[Validator] added support for grapheme_strlen when mbstring is not installed but intl is installed
removed separator of choice widget when the separator is null
Commits
-------
d675c28 [FrameworkBundle] Use Router instead of RouterInterface
ae7ae8d [FrameworkBundle] Moved router_listener from web to router.xml since it depends on the router
35a9023 [FrameworkBundle] Added isEnabled to Router commands, fixes#1467536d979 [Console] Added Command::isEnabled method that defines whether to add the command or not
Discussion
----------
[2.1] [Console] Added Command::isEnabled method
This addresses #1467.
The idea is to allow commands to evaluate whether they can run or not, since they are automatically registered.
- It's useful for the two router:* commands since they're optional (router can be disabled), but part of the FrameworkBundle that is not really optional.
- It could be useful for third party code as well.
- It's BC.
- aa95bb0d395810b29a3e654673e130736d9d1080 should address the issue in #1467, while the other commits just make sure the command is not registered at all if the router isn't standard.
One issue remains though:
- A few other services like twig helpers get the `ròuter` injected, this means that if there is really **no** router service defined, there is still an error. I'm not sure how to fix those beyond adding `on-invalid="null"` but I'm not sure if that's desirable. I guess we could argue that the router is a big candidate for replacement/suppression, and as such it should be truly optional, but if we do it I don't know where it'll lead. I don't want to end up in a situation where half the dependencies are optional to support every possible combination. @fabpot wdyt?
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/28 16:19:46 -0700
I'd rather see us not register a command instead of register and then disable it. Can we do the same thing you've done here in the bundle's registerCommands() method?
---------------------------------------------------------------------------
by Seldaek at 2011/06/28 16:51:36 -0700
Note that it's never really registered. During the registration it's checked and skipped if not enabled.
However, doing it as you suggest means overriding/copy-pasting all the code from the core Bundle class, which I don't like so much. It also means adding code specific to those two commands in a somewhat unrelated place, which I also don't like.
I'm not saying the current solution is perfect, but from the alternatives I considered, it's the best I have found.
---------------------------------------------------------------------------
by stof at 2011/09/04 04:58:04 -0700
@Seldaek your branch conflicts with master. could you rebase it ?
@fabpot what do you think about this PR ?
---------------------------------------------------------------------------
by Seldaek at 2011/09/04 08:39:05 -0700
Rebased
No other helpers have request scope and the assets helper's parameters don't appear to depend on the request in any way, so this appears to be unnecessary. As-is, request scope here prevents use of the assets helper from a console command that may need to internally render a template.
Commits
-------
b9b6084 [FrameworkBundle] Updated Czech translations for image validator
Discussion
----------
[FrameworkBundle] Updated Czech translations for image validator
---------------------------------------------------------------------------
by stof at 2011/09/10 12:10:08 -0700
Could you send a PR against the 2.0 branch for the trans-unit up to 41 which are already part of 2.0 ? Adding 42 to 46 should then still be done in master as they are new for 2.1
* 2.0:
[HttpKernel] fixed typo
fixed previous merge, done the same change to other occurences
fixes usage of mb_*
Profiler session import fixed.
[Process] workaround a faulty implementation of is_executable on Windows
Swedish translation fix.
[Locale] Fix#2179 StubIntlDateFormatter support yy format
Fixed fourth argument of Filesystem->mirror()
Commits
-------
e6e5146 [Translation] now support ResourceBundle
Discussion
----------
[2.1][Translation] now support ResourceBundle
support `.res` and `.dat` bundles
---------------------------------------------------------------------------
by marijn at 2011/09/08 08:59:39 -0700
There are a few references to `ressource`, I guess that is a typo...
---------------------------------------------------------------------------
by stealth35 at 2011/09/08 09:13:32 -0700
@marijn thank, done
---------------------------------------------------------------------------
by fabpot at 2011/09/11 00:42:37 -0700
Is it possible to add a dumper like we have for all other loaders?
---------------------------------------------------------------------------
by stof at 2011/09/11 03:46:39 -0700
Btw, you need to rebase your branch as it conflicts with master
---------------------------------------------------------------------------
by stealth35 at 2011/09/11 04:04:23 -0700
@fabpot it's more difficult (or the easy way it's to use `exec` with `derb`), I can create the text resources
@stof oki
---------------------------------------------------------------------------
by fabpot at 2011/09/11 23:52:19 -0700
@stealth35: Can you remove the `@api` tags? We will review what is included into the public API later on. thanks.
---------------------------------------------------------------------------
by stealth35 at 2011/09/12 04:18:07 -0700
@fabpot done
Commits
-------
a0a97c6 Removed executable bits from all php files
Discussion
----------
Removed executable bits from all PHP files
Some files had a file mode of 755 and this PR changes them to 644. The reason behind this is that git always thinks that those files are changed when accessing the repository via a samba share on windows (tested with PhpStorm).
---------------------------------------------------------------------------
by fabpot at 2011/09/09 05:51:30 -0700
That was on my radar too. Can you do the same for the 2.0 branch?
-- add missing files
-- tweak translation command files
-- dumpers are now responsive for writting the files
-- moved the twig extractor the bridge
-- clear temp files after unit tests
-- check the presence of dumper in translation writer
-- General cleaning of the code
-- clean phpDoc
-- fix PHPDoc
-- fixing class name in configuration
-- add unit tests for extractors (php and twig)
-- moved test to correct location
-- polish the code
-- polish the code
Commits
-------
b7c2a2e [FrameworkBundle] fixed typo in German validator translation
Discussion
----------
[FrameworkBundle] fixed typo in German validator translation
* 2.0:
[Validator] Sync polish translation
[FrameworkBundle] sanitize target arg in asset:install command
few optimisations for XliffFileLoader and XmlFileLoader
[FrameworkBundle] Sync the Russian translations
[FrameworkBundle] Added Dutch validator translation for trans-unit 41
[FrameworkBundle] Updated German validator translation
[FrameworkBundle] Fixed a typo in the translation file per @PeymanHR
Commits
-------
cf598de [FrameworkBundle] Updated the Chinese translations by @heccjj
e16ddcf [FrameworkBundle] Renamed validators.cn.xliff to validators.zh_CN.xliff
62da90a [FrameworkBundle] Fixed the Chinese translations by @heccjj
057cf2f Edited src/Symfony/Bundle/FrameworkBundle/Resources/translations/validators.cn.xliff via GitHub
Discussion
----------
[FrameworkBundle] Updated the Chinese translations
Commits
-------
c558b78 avoid rendering the `ChoiceType` separator if all `choices` are `preferred_choices`
Discussion
----------
avoid rendering the `ChoiceType` separator if all `choices` are `preferred_choices`
---------------------------------------------------------------------------
by fabpot at 2011/07/24 00:51:21 -0700
The same change should be made to the PHP template.
---------------------------------------------------------------------------
by fabpot at 2011/07/25 00:31:39 -0700
I forgot to ask you to add some unit tests too. Thanks.
---------------------------------------------------------------------------
by craue at 2011/07/25 10:23:34 -0700
Are you asking for PHPUnit tests? If so, unfortunately, I'm not able to add those because I haven't used PHPUnit yet. ;)
---------------------------------------------------------------------------
by lenar at 2011/07/25 12:47:51 -0700
I would prefer ```choises | length``` without spaces as everywhere else.
---------------------------------------------------------------------------
by lenar at 2011/07/25 12:50:32 -0700
@fabpot: Since <option disabled> is unclickable in browser (by HTML spec) this really doesn't change anything (something not there is as unclickable) except the the look when rendered. I have hard time to imagine what could become unit-testable here by this change.
---------------------------------------------------------------------------
by stof at 2011/07/25 13:03:47 -0700
@lenar unit testing is not about what the browser could do. What should be unit-tested is that an example will only preferred choices does not output the separator, which is exactly what this PR is about
---------------------------------------------------------------------------
by stof at 2011/07/25 13:04:03 -0700
@lenar unit testing is not about what the browser could do. What should be unit-tested is that an example will only preferred choices does not output the separator, which is exactly what this PR is about
---------------------------------------------------------------------------
by lenar at 2011/07/25 13:08:33 -0700
@stof: ok, put this way you are definitely right.
---------------------------------------------------------------------------
by craue at 2011/07/25 13:37:50 -0700
@lenar: You're right about the spaces. I'm using them in my projects but will remove them here for the sake of consistency.
---------------------------------------------------------------------------
by stloyd at 2011/07/25 13:40:40 -0700
@craue I will write today/tomorrow test to cover your code and send you PR.
---------------------------------------------------------------------------
by craue at 2011/07/25 14:00:26 -0700
@stloyd: That would be nice. But I'm still not that familiar with Git(Hub). Is there anything I have to take care of?
Also, I'd like to squash my three commits into one ... if this is possible for an open PR and if I find out how to do that easily. :D
---------------------------------------------------------------------------
by fabpot at 2011/07/26 00:18:22 -0700
@craue: yes, you should squash your commits into one and use `--force` when you push (the PR will automatically be updated accordingly).
Commits
-------
0832f4d Updated Persian translation
2a4fca8 translated validators resources into Persian
Discussion
----------
Persian translation
Added Persian validator translations
Commits
-------
be4b77d Updated Romanian translation
Discussion
----------
Updated Romanian translation
Updated Romanian translation for validation messages to match the latest messages.
Commits
-------
321dd45 Updated spanish and catalan translations
Discussion
----------
Updated spanish and catalan translations
Added new translations based on the indonesian updated file.
This commit also fixes exception pages when Twig is not enabled as a templating engine.
Instead of just displaying the raw Twig template as before, we now fallback to the default
exception handler introduced some time ago.
Commits
-------
9bcce9f fix tests
fc4787a fix non-extensible router
Discussion
----------
Router fix
Right now, the router is hard to overwrite (you need always a compiler pass). This commit fixes this.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 01:15:36 -0700
Why do you need a complier pass to override the router?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 01:47:47 -0700
How would you suggest to overwrite it?
Basically, I want to do something like this:
```yml
services:
router:
parent: router.default
class: MyClass
calls:
- [moreDeps, []]
```
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 05:07:19 -0700
Then maybe we should somehow support redefining services with the same name while keeping the old one as parent, otherwise we need this foo.default for every service out there?
---------------------------------------------------------------------------
by fabpot at 2011/07/18 06:30:34 -0700
as @Seldeak said, why do that for the router and not all services?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 06:38:39 -0700
I have designed the SecurityBundle this way where extension is encouraged.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 11:15:57 -0700
I should add that this is mainly a problem for services where you still want to use the semantic configuration that is provided by the bundle. For services which are not configured by the extension, this is not so much of an issue.
Anyway, if you don't want to merge it, just close the PR. I have no problem with using a compiler pass.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 11:55:11 -0700
We already have such a case with translator and translator.real. I will review the existing services to see where it makes sense to implement the same strategy.
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 12:20:55 -0700
I guess you'd do it anyway, but we should pick a winner between .real and .default
---------------------------------------------------------------------------
by lsmith77 at 2011/07/18 12:26:52 -0700
I would prefer ".default" as ".real" always confused me.
Commits
-------
61de80d [FrameworkBundle] Updated the Dutch validator translations for the changes in 95f7eedd63
Discussion
----------
[FrameworkBundle] Updated the Dutch validator translations
[FrameworkBundle] Updated the Dutch validator translations for the changes in 95f7eedd63
Commits
-------
ad2b224 [FrameworkBundle] Updated Russian translations.
95f7eed [FrameworkBundle] Fixed messages of the Choice constraint in all translations.
Discussion
----------
[FrameworkBundle] Fixes for all translations
Fixed the source messages of the choice contstraint for all translations, and re-sort messages.
And also updated Russian translations, added translations for all constraints.
Commits
-------
24e0d71 [FrameworkBundle] Fix a translatable string from the Form default validator
30d348d [Form] Make the default invalid message translatable
Discussion
----------
[Form] Translation
The first commit adds the ability to customize the default message when the form is invalid:
* Make it an option in the form builder,
* Allow placeholders in the message,
* The default value `This value is not valid` exists in the translation files.
The second commit updates a source string in the XLIFF files to make it translatable. All translations should be updated accordingly. The source string is from the [default validator](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/Validator/DefaultValidator.php#L27).
This PR should fix The issue #997.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 01:53:05 -0700
The first commit is not about making the message translatable, but to make it customizable (as the message is used for very different purposes depending on the Type).
---------------------------------------------------------------------------
by fabpot at 2011/07/11 01:55:11 -0700
The "This value is not valid" string should be added to the translation files too.
---------------------------------------------------------------------------
by vicb at 2011/07/11 02:02:51 -0700
@fabpot it was not translatable as the name was hardcoded in the message (instead of using a placeholder). So yes it becomes translatable now (and "customize"able as explained in the PR message).
I have also removed the form name from the default message as I don't think it brings any added value.
`This value is not valid` already exists in the translation files (see id=24).
Commits
-------
f359e3d Updated italian translations
Discussion
----------
Updated and corrected italian translations
---------------------------------------------------------------------------
by davideborsatto at 2011/07/10 12:41:29 -0700
Previously they were not translated that good, plus there were a few typos here and there.
Commits
-------
d53f312 changed "should" to "must" in message 6 and 7. also moved message 32 as replacement of message 5, according to note by yethee
e151c80 updated japanese translations
Discussion
----------
updated japanese translations
Please update japanese translations.
I picked up some messages from the latest sources of validation classes on your master branch, because translations for many other languages seems not to contain messages for recent validator classes, such as Image,Ip,Locale,Language.
Thanks in advance!
---------------------------------------------------------------------------
by yethee at 2011/07/10 09:23:01 -0700
> "One or more..." is on message#33 in my commit, should I locate #33 just after #5?
Not necessarily, the order of messages is not important, AFAIK.
Commits
-------
c1cab27 [FrameworkBundle] Updated Russian translations for validators.
Discussion
----------
[FrameworkBundle] Updated Russian translations for validators.
Sync translations with the actual validator constraints.
Removed some translations (they are not found among the constraints):
- `This value should be instance of class {{ class }}`
- `This field group should not contain extra fields`
- `The uploaded file was too large. Please try to upload a smaller file`
Commits
-------
8a6ac0c Added Romanian translations for validators
Discussion
----------
[Validator] Added Romanian translations
Added all strings up to commit SHA: d58ba34246
Commits
-------
d58ba34 [Validator] Consider the ini directive 'upload_max_filesize' while validating an uploaded file (fixes GH-1441)
Discussion
----------
[Validator] FileValidator support for uploaded files
[Validator] Consider the ini directive 'upload_max_filesize' while validating an uploaded file (fixes GH-1441)
Added validator messages should get translated in all the available languages.
Commits
-------
aeaf44a Removed unused code from DateTimeType
3c2539f Throw exception when "date_widget" option is not equal to "time_widget"
305c476 Overwrite child options ("widget", "empty_value") if any given
7bc19f9 Added to `DateTimeType` extension possibility to render form as `single_text` (similar to `DateType` option) (issue #1323 it requires fix for #1205)
17b41b2 Added to `TimeType` extension possibility to render form as `single_text` (similar to DateType option) (issue #1205) Adjusted `DateTimeType` to allow usage of this new feature
Discussion
----------
[Form][DateTimeType] Added "widget" and "empty_value" options
Hey,
I have just added "widget" and "empty_value" options to `DateTimeType`:
* `widget` option will overwrite existing `date_widget` and `time_widget`,
* `empty_value` behave exacly same way as it does for `ChoiceType`, `DateType` and `TimeType`
Also added and `FormException` when `date_widget` is not equal to `time_widget`, now is throwed non intuitive one (this will be changed in next days to allow different values for this options).
Closes#1323
Commits
-------
2cf7136 [FrameworkBundle][Form] tweak the choice widget PHP template
Discussion
----------
[FrameworkBundle][Form] tweak the choice widget PHP template
* make theming easier,
* factorize code,
* make PHP similar to Twig (easier to maintain)
Commits
-------
4e3406d Sync with master and clean up
ad5d2c1 Added to `TimeType` extension possibility to render form as `single_text` (similar to DateType option) (issue #1205) Adjusted `DateTimeType` to allow usage of this new feature
Discussion
----------
[Form][TimeType] Added possibility to render form as "single_text"
Added to `TimeType` extension possibility to render form as `single_text` (similar to `DateType` option) (issue #1205)
Adjusted `DateTimeType` to allow usage of this new feature
---------------------------------------------------------------------------
by ouardisoft at 2011/06/17 03:41:18 -0700
+1
---------------------------------------------------------------------------
by stloyd at 2011/06/21 01:05:51 -0700
@fabpot Any decision about this one ? I'm asking because I also have similar fix for #1323 but it requires this one ;-)
---------------------------------------------------------------------------
by fabpot at 2011/06/22 23:32:08 -0700
@stloyd: Can you rebase to master?
---------------------------------------------------------------------------
by stloyd at 2011/06/23 05:03:44 -0700
@fabpot Done.
Commits
-------
5d46e63 [Form] Add the FormHelper configuration
a43fad4 [Form] Improve unit tests for rendering
1cb2129 [FrameworkBundle][Form] Adding a cache to FormHelper::lookupTemplate()
f39ce67 [Form][FrameworkBundle] PHP theming
Discussion
----------
[2.1] RFC [Form] Php theming
This PR implements theming support for the php engine.
It works similarly as the twig theming with themes being folders and blocks being individual files.
There are probably a few things to tune before this can get merged:
### Theme naming
The current format is "\<Bundle\>:\<Controller\>" i.e. "FrameworkBundle:Form".
Is this ok or could you imagine something better ?
### Div and Table theme folders
Currently "FrameworkBundle\\Resources\\views\\Form" and "FrameworkBundle\\Resources\\views\\FormTable"
Is this ok or anything better ?
### Form helper configuration
I am not sure if the configuration is at the best possible location:
```
framework:
templating:
form:
resources: [themeA, themeB]
```
Any better idea ?
There is a [thread on the ml](http://groups.google.com/group/symfony-devs/browse_thread/thread/9b3f131fe116b511)
Commits
-------
2c1108c [Form] Revert the ability to override anything else than the text of the label while rendering a row
da467a6 [Form] Fix the exception message when no block is found while rendering
8670995 [Form] Optimize rendering when the block to render is known
41e07c9 [Form] Optimize rendering
ee5d975 [Form] Remove a test which is no more relevant (after recent FileType refactoring)
f729c6b [Form] Add the ability to override label & widget options when rendering a row
e09ae3f [Form][FrameworkBundle] Make FormHelper::renderSection() recursively callable, introduce FormHelper::renderBlock()
e43fb98 [Form][TwigBridge] Make FormExtension::render() recursively callable to ease theming
Discussion
----------
[Form] Some refactoring of the rendering
# First two commits
## FormExtension::render() can now be called recursively.
The main use case is theming support in for collections. Let's consider that you have a collection of `CustomType`, the type hierarchy while rendering the proto would be `field < form < custom < prototype`. Before this change any theme applied to your custom type (i.e. a `custom_row` block) would not have been taken into account while rendering the prototype because of the structure of the `prototype_row` block:
```html
{% block prototype_row %}
{% spaceless %}
<script type="text/html" id="{{ proto_id }}">{{ block('field_row') }}</script>
{% endspaceless %}
{% endblock prototype_row %}
```
which skip the `custom_row` block rendering to fallback to the `field_row` block rendering.
With this PR `prototype_row` recursively calls `FormExtension::render()`
```html
{% block prototype_row %}
{% spaceless %}
<script type="text/html" id="{{ proto_id }}">{{ form_row(form) }}</script>
{% endspaceless %}
{% endblock prototype_row %}
```
this has for effect to render the block for the parent type (i.e. `custom_row`)
## FormHelper
The `FormHelper` has been updated to more closely match the `FormExtension` architecture and the templates have been modified accordingly. `echo $view['form']->renderBlock(<block name>)` is the php equivalent of `{{ block(<block name>) }}`.
The attributes are now rendered using a template rather than by the `FormHelper::attributes()` method.
Several templates have been fixed.
# Third commit
The `$varStack` property was used to forward options to the label and the widget when rendering a row. The implementation was not working as expected. The proposed way to override label and widget options is to pass these options in the `label` and `widget` keys while callinf `render_row`.
That would be:
`{{ form_row(form.field, {"attr": {<row attributes>}, "label" : {"label": <text>, "attr": {<label attr>}}, "widget" : { "attr" : {<widget attributes}} } }}`
So there is now the ability to set attributes for the row (`<div>` or `<tr>`).
This has been discussed on [the mailing list](http://groups.google.com/group/symfony-devs/browse_thread/thread/17754128ba480545). **I would like to find a compromise with @Seldaek before this gets merged**
The `$varStack` property is now only used when recursively calling `FormExtension::render()`
# Notes
I have preferred to submit several commits in order to ease review and to keep some history.
---------------------------------------------------------------------------
by stof at 2011/06/20 05:20:56 -0700
@vicb On a side note, do you think it would be possible to support form theming in PHP templates too ? Currently, the only way to customize the rendering of forms when using PHP templates is to overwrite the FrameworkBundle's templates, and this impacts all forms. This makes the PHP rendering far less powerful than the Twig one.
I don't know the Form rendering and the PHPEngine well enough to know if it is feasible for 2.1 or not.
---------------------------------------------------------------------------
by vicb at 2011/06/20 05:35:11 -0700
@stof I hope to make it possible but I need a little bit more thinking to find the best possible solution which should not look like a hack.
---------------------------------------------------------------------------
by vicb at 2011/06/21 01:13:10 -0700
This should not be merged yet, it might have some issue with the variable stack. I am working on it.
---------------------------------------------------------------------------
by vicb at 2011/06/21 01:41:11 -0700
Sorted out the issue, it was linked to some local _optimization_, the code of this PR is ok.
---------------------------------------------------------------------------
by vicb at 2011/06/21 02:01:24 -0700
I have pushed a [POC of php theming based on this PR](https://github.com/vicb/symfony/commits/form%2Fphp-theme) to my repo - it is lacking a configuration and cache layer.
I have open [a thread on the ml](http://groups.google.com/group/symfony-devs/browse_thread/thread/9b3f131fe116b511) to discuss this.
---------------------------------------------------------------------------
by vicb at 2011/06/21 23:40:21 -0700
@fabpot fixed in the last commit.
Rules are as follows:
* If multiple is true, then the empty_value is ignored
* If not, and if the field is not required, the empty_value is set to the empty string by default and displayed
* If the field is required, and if the user explicitely set the empty_value, then it is displayed
* kriswallsmith/form/collection-proto:
added script[type="text/html"] collection prototype to form themes
[Form] removed collection prototype from form tree
The current implementation is not ready for inclusion in 2.0. It has several
known problems (security, not possible to disable it, not "cloud-compatible",
...) and it's not a must have feature anyway.
Some references:
* Security issue in FileType: https://github.com/symfony/symfony/issues/1001
* Validation fails on file, still stored in TemporaryStorage: https://github.com/symfony/symfony/issues/908
* Add a size argument & ability to configure TemporaryStorage: https://github.com/symfony/symfony/pull/748
This feature should be reworked and discussed for inclusion in 2.1.
* vicb/form-rendering-fix:
[Form] Fix accessibility for file inputs
[FrameworkBundle] Fix the FormHelper phpDoc
[FrameworkBundle][Form] Add some phpDoc for the FormHelper class
[FrameworkBundle][Form] Fix label rendering
[FrameworkBundle][Form] Fix rendering search inputs in PHP
[Form] FormType labels should never have a for attribute
[Form] Never render a view again
Here are the new simplified rules:
* Required cache warmers are *always* executed when the Kernel boots for the first time;
* Optional cache warmers are *only* executed from the CLI via cache:warmup
These new rules means that all the configuration settings for the cache
warmers have been removed. So, if you want the best performance, remember to
warmup the cache when going to production.
This also fixed quite a few bugs.
* Seldaek/events:
[EventDispatcher] Removed temporary code
[FrameworkBundle] Improved code readability
[FrameworkBundle] Clarified code and fixed regression
Update Core and Security events to latest model
[EventDispatcher] Allow registration of arbitrary callbacks
[EventDispatcher] Remove useless code
[EventDispatcher] Minor memory optimization to getListeners()
[FrameworkBundle] Small optimization, remove some function calls
The main benefit is that in XML/YML files we have common syntax (i.e. core.controller, form.pre_bind) that properly namespaces event names (before: onCoreController was ok, preBind was not).
On the other hand in PHP land we also have namespaced events, CoreEvents::controller, FormEvents::preBind, before it was Events::onCoreController, Events::onPreBind, we now have more context.
* bschussek/form_validator:
[Form] Renamed the value "text" of the "widget" option of the "date" type to "single-text"
[Form] Implemented getAllowedOptionValues() for core types
[Form] Removed unused option
[Form] Added FormTypeInterface::getAllowedOptionValues() to better validate passed options
[Form] Improved test coverage of FormFactory and improved error handling
[Form] Added getType() to FormFactoryInterface
[Validator] Refactoring DateTimeValidator and DateValidator
[Validator] Date: check if the value is a DateTime instance
Running it before other onCoreResponse listeners avoids seeing them
as called listeners in the event panel. The priority is set to -100
because it has to be called before the WebProfilerListener (-128) so
that the token is set.