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.
Commits
-------
9d8e6f6 [FrameworkBundle] Changed TraceableEventDispatcher to log calls to event listeners _before_ actually calling them
Discussion
----------
[FrameworkBundle] Log calls to event listereners _before_ calling them
The current implementation of `TraceableEventDispatcher` logs calls to event listeners _after_ actually calling them. This leads to strange logs when an event listener triggers another event.
For example, if I attach some `LoginListener` to the `security.interactive_login`-event, the log will look something like this:
<pre>
...
User "myusername" has been authenticated successfully
Notified event "security.interactive_login" to listener "MyVendor\MyBundle\EventListener\LoginListener::onSecurityInteractiveLogin".
Notified event "kernel.request" to listener "Symfony\Component\Security\Http\Firewall::onKernelRequest".
...
</pre>
From the logs it looks like the `kernel.request` event was fired after the user was authenticated, whereas it was actually the listener to `kernel.request` that caused the user to be authenticated.
By logging the call to the event listener _before_ calling it, the logs will look like this:
<pre>
...
Notified event "kernel.request" to listener "Symfony\Component\Security\Http\Firewall::onKernelRequest".
Notified event "security.interactive_login" to listener "MyVendor\MyBundle\EventListener\LoginListener::onSecurityInteractiveLogin".
User "myusername" has been authenticated successfully
...
</pre>
In my opinion this makes the causal relationship between the events clearer.
---------------------------------------------------------------------------
by stof at 2011/07/24 11:18:48 -0700
👍 for this.
Commits
-------
266e60e Don't tell a lie to every WebServers
Discussion
----------
Please don't tell a lie to every WebServers
Fake Useragent name should be only in test case .
Commits
-------
eae6a77 fixed wrong case
d0a175bfixes#1659f300ede fixes several bugs
a4f05ac added some tests
Discussion
----------
Http util fixes
Fixes several bugs in the http utils.
Please don't add anymore features without sufficient tests. Especially for the Security\Http namespace, regressions are very likely otherwise.
---------------------------------------------------------------------------
by fabpot at 2011/07/19 22:37:26 -0700
Tests do not pass for me:
There were 2 errors:
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #0 ('en')
InvalidArgumentException: The current node list is empty.
.../src/Symfony/Component/DomCrawler/Crawler.php:604
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:16
2) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #1 ('de')
InvalidArgumentException: The current node list is empty.
.../src/Symfony/Component/DomCrawler/Crawler.php:604
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:16
--
There were 4 failures:
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResource with data set #0 ('en')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-http://localhost/en/login
+http://localhost/login
.../src/Symfony/Bundle/Securitybundle/Tests/Functional/WebTestCase.php:22
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:38
2) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResource with data set #1 ('de')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-http://localhost/de/login
+http://localhost/login
.../src/Symfony/Bundle/Securitybundle/Tests/Functional/WebTestCase.php:22
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:38
3) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResourceWithForward with data set #0 ('en')
HTTP/1.0 302 Found
Cache-Control: no-cache
Content-Length: 299
Content-Type: text/html; charset=UTF-8
Date: Wed, 20 Jul 2011 05:36:27 GMT
Location: http://localhost/login
Set-Cookie: PHPSESSID=11c9c6a7e7620e13bddef223a5ba46d9; path=/; domain=
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="refresh" content="1;url=http://localhost/login" />
</head>
<body>
Redirecting to <a href="http://localhost/login">http://localhost/login</a>.
</body>
</html>
Failed asserting that <integer:0> matches expected <integer:1>.
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:50
4) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testAccessRestrictedResourceWithForward with data set #1 ('de')
HTTP/1.0 302 Found
Cache-Control: no-cache
Content-Length: 299
Content-Type: text/html; charset=UTF-8
Date: Wed, 20 Jul 2011 05:36:28 GMT
Location: http://localhost/login
Set-Cookie: PHPSESSID=2bbe63786a088471ade3717917f4ba4f; path=/; domain=
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="refresh" content="1;url=http://localhost/login" />
</head>
<body>
Redirecting to <a href="http://localhost/login">http://localhost/login</a>.
</body>
</html>
Failed asserting that <integer:0> matches expected <integer:1>.
.../src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php:50
---------------------------------------------------------------------------
by schmittjoh at 2011/07/19 23:47:29 -0700
I fixed a wrong case, but I couldn't reproduce the other errors (tested on Ubuntu).
My guess is that the temporary directory on your machine couldn't be deleted for some reason, and the test runs with the configuration of some of the previous tests.
---------------------------------------------------------------------------
by fabpot at 2011/07/20 00:28:41 -0700
That does not make any difference for me. For instance, in `LocalizedRoutesAsPathTest::testLoginLogoutProcedure()`, the first request to `'/'.$locale.'/login'` returns the following Response:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="refresh" content="1;url=http://localhost/login" />
</head>
<body>
Redirecting to <a href="http://localhost/login">http://localhost/login</a>.
</body>
</html>
---------------------------------------------------------------------------
by schmittjoh at 2011/07/20 00:31:34 -0700
That's weird, did you make sure that the temporary directory does not exist?
``rm -Rf /tmp/StandardFormLogin/``
On Wed, Jul 20, 2011 at 9:28 AM, fabpot <
reply@reply.github.com>wrote:
> That does not make any difference for me. For instance, in
> `LocalizedRoutesAsPathTest::testLoginLogoutProcedure()`, the first request
> to `'/'.$locale.'/login'` returns the following Response:
>
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;
> charset=utf-8" />
> <meta http-equiv="refresh" content="1;url=
> http://localhost/login" />
> </head>
> <body>
> Redirecting to <a href="http://localhost/login">
> http://localhost/login</a>.
> </body>
> </html>
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1739#issuecomment-1613504
>
---------------------------------------------------------------------------
by fabpot at 2011/07/20 00:33:40 -0700
Yes, I've just checked and the directory does not exist.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/20 00:39:55 -0700
Sorry, I can't reproduce it on Ubuntu and unless someone wants to sponsor me a Mac, there is not much I can do.
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.
when esi is enabled and internal uris are generated for esi-tags, an
attribute-array consisting entirely of null-values isn't handled correctly.
The reason is that php's `http_build_query()`-method outputs an empty string
for such arrays:
http_build_query(array('foo' => '')) == 'foo='
http_build_query(array('foo' => null)) == ''
In the latter case, the generation of an URI in `HttpKernel::generateInternalUri()`
generates an URI that could not be matched by the corresponding route (ex.
`_internal/Controller/.html` opposed to `_internal/Controller/none.html` which
should be expected).
This commit adds a possible solution as well as a simple test for this issue.
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
-------
8e169e4 Improved performance when assetic's use_controller is enabled
Discussion
----------
Improved performance when assetic's use_controller is enabled
When assetic's use_controller is enabled, assetic has to loop through all the templates and create TemplateReferences through the assetic FileResource. This in turn causes a lot of calls to getLogicalName() leading to 5x the calls to the TemplateReference's get() (16k in my case). By accessing the protected field directly compared to using get() we achieve better performance during development (33% in my case).
---------------------------------------------------------------------------
by beberlei at 2011/07/18 11:22:43 -0700
+1 - assetic is a huge performance drain for my app in dev mode aswell.
Commits
-------
872d308 [DoctrineBundle] Allowed to configure dql functions without using the multiple entity mangers syntax
Discussion
----------
[DoctrineBundle] Allowed to configure dql functions using the single EM syntax
[DoctrineBundle] Allowed to configure dql functions without using the multiple entity managers syntax
When assetic's use_controller is enabled, assetic has to loop through all the templates and create TemplateReferences through the assetic FileResource. This in turn causes a lot of calls to getLogicalName() leading to 5x the calls to the TemplateReference's get() (16k in my case). By accessing the protected field directly compared to using get() we achieve better performance during development (33% in my case).
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
-------
66c698a Updated update.md
b33e1ba [SecurityBundle] Reported namespace change of EntityUserProvider
26e96c4 [DoctrineBridge] Changed namespace of EntityUserProvider[B
1633cb3 [Security] Moved EntityUserProvider to Doctrine Bridge
Discussion
----------
[2.1] Moved EntityUserProvider class from Security Component to Doctrine Bridge
I guess that this should better be placed in the Doctrine Bridge.
---------------------------------------------------------------------------
by henrikbjorn at 2011/07/13 00:00:39 -0700
Missing entry in UPDATE.md
---------------------------------------------------------------------------
by schmittjoh at 2011/07/13 00:34:10 -0700
What is our distribution strategy for these bridges?
---------------------------------------------------------------------------
by stof at 2011/07/13 00:53:29 -0700
@schmittjoh Each bridge (Doctrine, Twig, Monolog) is available as a separate repo just like the components.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/13 00:57:41 -0700
I've just checked, but we don't seem to have PEAR packages for these.
If we make this change, then it should still be easy to install the component because there is no benefit of moving this class there. The bridges are mainly useful for extracting code from bundles.
---------------------------------------------------------------------------
by stof at 2011/07/13 01:02:42 -0700
@fabpot any plan to add the bridges on the PEAR channel ?
---------------------------------------------------------------------------
by fabpot at 2011/07/13 02:27:05 -0700
@stof: Bridges will be added with the RC5 release.
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
-------
91cfb24 Made namespace for Doctrine cache unique to each environment
Discussion
----------
Made the cache namespace for the Doctrine cache extension unique to each environment
The current cache namespace for the Doctrine adapters is unique on an entity manager and the kernel root directory; however, it causes problems as settings for entity managers can differ between environments, so the addition of the environment into the namespace would address the issue.
$namespace = 'sf2orm_'.$entityManager['name'].'_'.md5($container->getParameter('kernel.root_dir'));
Solves issues with the cache not being valid for the DBAL ACL provider using D2 as the cache and switching environments.
An exception has been thrown during the rendering of a template ("Warning: Illegal offset type in isset or empty in ../vendor/symfony/src/Symfony/Component/Security/Acl/Dbal/AclProvider.php line 404")
Commits
-------
df34e0e [FrameworkBundle] Fix for setting a custom file link format (fixes#1652)
Discussion
----------
[FrameworkBundle] Fix for setting a custom file link format (fixes#1652)
[FrameworkBundle] Fix for setting a custom file link format (fixes#1652)
Solves issues with the cache not being valid for the DBAL ACL provider using D2 as the cache and switching environments.
An exception has been thrown during the rendering of a template ("Warning: Illegal offset type in isset or empty in ../vendor/symfony/src/Symfony/Component/Security/Acl/Dbal/AclProvider.php line 404")
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
-------
f8b5f35 [MonologBundle] Refactored the way to configure the email prototype for swiftmailer
874fb95 [MonologBundle] Refactored the configuration of processors
Discussion
----------
Monolog
This refactors the way processors and email prototype are configured in MonologBundle for consistency with the other bundles. The hack using ``@id`` to use a service in the semantic configuration is not used anywhere else in Symfony2.
This removes the ability to use a static callback as processor (or a PHP function) but adds the support of adding a processor only for a given logging channel (for processors attached to the logger) which was not possible previously.
---------------------------------------------------------------------------
by stof at 2011/07/06 07:33:52 -0700
the PR for the doc and the standard edition are coming.
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
-------
bcca47a missing argument to addProcessors()
Discussion
----------
[MonologBundle] Missing argument to addProcessors()
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 07:03:45 -0700
@fabpot: Please merge, this is a regression in yesterday's PR
Commits
-------
2af2260 Remove useless code
Discussion
----------
Remove useless code
This PR is about removing useless code which could benefit to perfomances.
Credits go to [Jordi](https://github.com/symfony/symfony/commit/000229dbd0d161f1eebe) for this.
As a minor modif, I can understand if this could not be merged while in RC.
Commits
-------
bf76bed Correct prefix from nothing to ORM\ for annotations
Discussion
----------
Correct prefix from nothing to ORM\ for annotations
For yml et xml mapping, the commands generate:doctrine:entities and doctrine:generate:entities, don't prefixed the annotations, specially for the listenners methods (prepersist, preupdate...).
Commits
-------
c867209 Adjust UPDATE.md to Annotation changes
9069d06 Fix tests to run with Doctrine Common AnnotationRegistry
d5c1bbe Disable call to AnnotationReader::setAutoloadAnnotations()
Discussion
----------
Annotation autoloading
This pull request disables the annotation autoloading through the DIC. PHP Autoloading is now removed from the AnnotationReader and replaced with its own autoloading mechanism that offers much more control over possible error states.
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)
This change removes the need for the {_locale} hack.
Now, all paths in the Security component can be:
* An absolute path (/login)
* An absolute URL (http://symfony.com/login)
* A route name (login)
So, if you want to use a path that includes a global parameter (like _locale),
use a route instead of a path.
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.
Commits
-------
abd60ac [WebProfilerBundle] Do not display toolbar loading result if it's not a valid toolbar
406c8d8 [WebProfilerBundle] Make toolbar loading non-blocking
Discussion
----------
Non-blocking WDT & prevents garbage to slip in the page
I made the loading non-blocking so that it's not preventing normal operation of the page when the WDT takes a bit long to come up (happens sometimes when the machine is busy).
The second commit also checks that the response looks correct, to prevent stack traces and such to appear in the page if there was a problem. The main issue is not really stack traces though it's mostly with security and intercept_redirect enabled, if you look at a fully secured site you get twice the redirect intercept message to the login page.
Tested in IE7/9/FF4/Opera11
Commits
-------
f315ad9 [WebProfilerBundle] Make sure the toolbar closes properly
Discussion
----------
[WebProfilerBundle] Make sure the toolbar closes properly
Due to the whitespace element between the div which clears and the toolbar div, in some browsers it was left over after you close the toolbar, this doesn't happen anymore.
Tested in IE7/9/FF4/Opera11
Commits
-------
6c46a3b [FrameworkBundle] Prevent breakage when an array callback is not callable
Discussion
----------
[FrameworkBundle] Prevent breakage when an array callback is not callable
W/o this you get warnings that objects can't be converted to strings.
Commits
-------
72d0ebe9 [WebProfilerBundle] Added the support of the the logging context in the template
410b3e0 [HttpKernel] Added the context in the LoggerInterface
Discussion
----------
context in the LoggerInterface
This adds the context in the LoggerInterface. The change is totally BC for people using the logger. However this affects people implementing the interface.
Note that this require Seldaek/monolog#33 for the implementation
---------------------------------------------------------------------------
by Seldaek at 2011/06/17 04:24:18 -0700
@fabpot: just ping me when you are merging this one, so I can merge in monolog and we avoid out-of-sync issues.
---------------------------------------------------------------------------
by stof at 2011/06/17 04:49:05 -0700
@Seldaek you can merge in Monolog when you want. Monolog is BC so merging it before the PR in Symfony2 does not break things.
---------------------------------------------------------------------------
by Seldaek at 2011/06/17 05:08:34 -0700
Ah right, I thought the interfaces wouldn't match, but PHP allows extra args it seems so I'll merge right now.
---------------------------------------------------------------------------
by stof at 2011/06/17 05:32:58 -0700
PHP allows extra *optionnal* args and it is the case here :)
---------------------------------------------------------------------------
by Seldaek at 2011/06/17 05:35:00 -0700
Well yes otherwise you break the interface. Anyway it's merged so @fabpot, anytime :)
Commits
-------
5b0f1da [HttpKernel] made WebTestCase methods static
Discussion
----------
[HttpKernel] made WebTestCase methods static
This makes it possible to load fixture data in `::setUpBeforeClass()` which makes tests run much faster.
Also, `createClient()` is not protected instead of public; I'm not sure why it was public in the first place.
Commits
-------
edf4b87 Add missing "tearDown" functions, and some missing variable declaration (this saves for me almost 20MB when run all tests) Force AsseticBundle tests to use TestCase Fix test for DoctrineBundle to use TestCase
2b0c352 Increase code coverage for: YamlParser, Validators, PhpEngine + Helpers, HttpFoundation
b88a0a0 Remove tabs
99f9337 Additional tests for PhpEngine + Helpers More tests for UrlValidator
450ed85 Additional tests for DateTimeValidator, EmailValidator and UrlValidator
Discussion
----------
[Tests] Cleanup + make code coverage more happy
Hey,
this PR is a bit bigger than usually ;-) few infos what's inside:
- Fix `DoctrineBundle` test to use `TestCase`
- Mark tests as "incomplete" instead of commenting them out
- Increase code coverage for: `Validators`, `PhpEngine` + `Helpers`, `HttpFoundation` (`Session`, `Response` etc.)
- And my favourite ;-) added missing variables definition (also removed non-used) and `tearDown()` function (if needed) to tests which allowed me saved __~15MB__ when running all tests
---------------------------------------------------------------------------
by stloyd at 2011/06/16 05:58:21 -0700
@fabpot & @marcw It was rebased and cleanup up (I split up `AsseticBundle` symfony/AsseticBundle#1 change to new repo), and added few new tests.
Commits
-------
cdf4b6a Checked log levels
a45d3ee Reverted last commit
529381b ControllerNotFound: Changed log level from info to error. Also moved throw exception code block up, to prevent the message from beeing logged multiple times.
7c29e88 Changed log level of "Matched route ..." message from info to debug
dca09fd Changed log level of "Using Controller ..." message from info to debug
Discussion
----------
Log levels
Just wanted to ask if the log level INFO is still correct for these messages?
As there are only four log levels left (DEBUG, INFO, WARNING, ERROR), DEBUG might be the more appropriate level for these messages now.
Let me give an example: An application is logging user actions (maybe to database) in order to assure comprehensibility, e. g. "User %s deleted post %d", "User %s written a message to user %s". These are not warnings of course, so the only suitable log level is INFO.
But they will be thrown together with these very common (at least two per request?) "Using controller..." and "Matched route..." messages when choosing INFO as log level.
---------------------------------------------------------------------------
by Seldaek at 2011/05/24 07:13:18 -0700
Agreed, this stuff is framework debug information.
---------------------------------------------------------------------------
by fabpot at 2011/05/24 08:53:24 -0700
Why do you want to change these two specific ones? The framework uses the INFO level at other places too. Is it a good idea to say that the framework only logs with DEBUG?
---------------------------------------------------------------------------
by stof at 2011/05/24 09:12:53 -0700
Doctrine logs at the INFO level too and I think it is useful to keep it as INFO. Being able to see the queries without having all DEBUG messages of the event dispatcher and security components is useful IMO.
---------------------------------------------------------------------------
by Seldaek at 2011/05/25 02:30:24 -0700
Yeah, that's true, maybe we just need to reintroduce (again, meh:) NOTICE between INFO and WARNING.
@kaiwa Of course the other way could be that you just add your DB handler to the app logger stack. That could be done in a onCoreRequest listener or such, basically you'd have to call `->pushHandler($yourDBHandler)` on the `monolog.logger.app` service. That way your messages will flow to it, but it won't receive noise from the framework stuff since those log on monolog.logger.request and other log channels.
---------------------------------------------------------------------------
by fabpot at 2011/05/25 02:48:26 -0700
@Seldaek: I don't think we need another level. We just need to come up with a standard rules about the usage of each level. Adapted from log4j:
* ERROR: Other runtime errors or unexpected conditions.
* WARN: Use of deprecated APIs, poor use of API, 'almost' errors, other runtime that are undesirable or unexpected, but not necessarily "wrong" (unable to write to the profiler DB, ).
* INFO: Interesting runtime events (security infos like the fact the user is logged-in or not, SQL logs, ...).
* DEBUG: Detailed information on the flow through the system (route match, security flow infos like the fact that a token was found or that remember-me cookie is found, ...).
What do you think?
---------------------------------------------------------------------------
by stloyd at 2011/05/25 02:53:38 -0700
+1 for this standard (also this PR can be merged then), but we should review code for other "wrong" log levels usage (if everyone accept this standard)
---------------------------------------------------------------------------
by fabpot at 2011/05/25 02:55:07 -0700
I won't merge this PR before all occurrences of the logger calls have been reviewed carefully and changed to the right level.
---------------------------------------------------------------------------
by kaiwa at 2011/05/25 02:58:44 -0700
@fabpot: Just noticed these two occurring for every request in my log file. You are right, there are other places where this changes must be applied if we will change the log level.
@stof: Hmm, i see. It is not possible to set the logger separately for each bundle, is it? That maybe would solve the problem. If somebody is interested in seeing the queries, he could set the log handler level to DEBUG for doctrine bundle, but still use INFO for the framwork itself. Plus he could even define a different output file or a completely different handler.
I'm not sure if something like that is possible already (?) or realizable at all... just came into my mind.
---------------------------------------------------------------------------
by Seldaek at 2011/05/25 03:01:07 -0700
Just FYI, from Monolog\Logger (which has CRITICAL and ALERT):
* Debug messages
const DEBUG = 100;
* Messages you usually don't want to see
const INFO = 200;
* Exceptional occurences that are not errors
* This is typically the logging level you want to use
const WARNING = 300;
* Errors
const ERROR = 400;
* Critical conditions (component unavailable, etc.)
const CRITICAL = 500;
* Action must be taken immediately (entire service down)
* Should trigger alert by sms, email, etc.
const ALERT = 550;
The values kind of match http error codes too, 4xx are expected errors that are not really important (404s etc) and 5xx are server errors that you'd better fix ASAP. I'm ok with the descriptions, but I think alert and critical should be included too. I'll probably update Monolog docblocks to match whatever ends up in the docs.
---------------------------------------------------------------------------
by Seldaek at 2011/05/25 03:03:21 -0700
@kaiwa you can do a lot, but not from the default monolog configuration entry, I'm not sure if we can really make that fully configurable without having a giant config mess. Please refer to my [comment above](https://github.com/symfony/symfony/pull/1073#issuecomment-1234316) to see how you could solve it. Maybe @fabpot has an idea how to make this more usable though.
---------------------------------------------------------------------------
by stof at 2011/05/25 03:19:43 -0700
@Seldaek the issue is that the different logging channels are only know in the compiler pass, not in the DI extension. So changing the level in the extension is really hard IMO.
Thus, the handlers are shared between the different logging channels (needed to open the log file only once for instance, or to send a single mail instead of one per channel) and the level is handled in the handlers, not the logger.
I'm +1 for the standard, by adding the distinction between 400 and 500 status calls using ERROR and CRITICAL (which is already the case in the code).
@kaiwa do you have time to review the calls to the logger between DEBUG and INFO or do you prefer I do it ? For instance, the Security component currently logs all message at DEBUG level and some of them should be INFO.
---------------------------------------------------------------------------
by kaiwa at 2011/05/25 04:31:04 -0700
@stof ok i'll do that
---------------------------------------------------------------------------
by kaiwa at 2011/05/25 12:22:51 -0700
Need some help :) I came across `ControllerNameParser::handleControllerNotFoundException()` which leads to redundant log messages currently:
>[2011-05-25 20:53:16] request.INFO: Unable to find controller "AppBaseBundle:Blog" - class "App\BaseBundle\Controller\BlogController" does not exist.
>[2011-05-25 20:53:16] request.ERROR: InvalidArgumentException: Unable to find controller "AppBaseBundle:Blog" - class "App\BaseBundle\Controller\BlogController" does not exist. (uncaught exception) at /home/ruth/symfony3/src/Symfony/Bundle/FrameworkBundle/Controller/ControllerNameParser.php line 87
Is it necessary to call `$this->logger->info($log);` if the InvalidArgumentException will be logged anyway?
---------------------------------------------------------------------------
by stof at 2011/05/25 12:39:22 -0700
Well, the issue is that the ControllerNameParser logs messages and then uses them to throw an exception. I guess the logging call should be removed as it is redundant with the one of the ExceptionListener. @fabpot thoughts ?
---------------------------------------------------------------------------
by kaiwa at 2011/05/27 11:39:25 -0700
I checked all debug, info and log calls. Sometimes it is hard to distinguish between the levels, so it would be great if someone reviews @cdf4b6a. @stof, maybe you want to take a look?
---------------------------------------------------------------------------
by kaiwa at 2011/05/31 12:52:07 -0700
@stof, thanks for your comments. I added some replies above, please let me know your suggestions.
---------------------------------------------------------------------------
by stof at 2011/05/31 14:04:22 -0700
@kaiwa As I said before, all the security logging calls should be DEBUG (most of them) or INFO (the one syaing that authentication succeeded for instance), but not WARN or ERROR as the exception don't go outside the firewall.
The blackhole plugin that was used previously stop the propagation
of events, which means that the behavior can be slightly different
depending on the order of plugin registrations.
Instead, we now use the null transport to avoid this issue.
Commits
-------
07fa82d [Form] Revert changes impacting perfomance and readability
b709551 [Order] Make Form::types and FormView::types use the same order (Parent > Child)
e56dad6 [Form] simplify the code
bdd755e [Form] Fix the exception message when no block is found
c68c511 [Form] Make theming form prototypes consistent (start by looking for a '_<id>_<section>' block)
9ec9960 [Form] Simplify the code
4e3e276 [Form] Make the prototype view child of the collection view
Discussion
----------
[Form] Make the prototype view child of the collection view
This PR should be a base for discussion.
The [current implementation](https://github.com/symfony/symfony/pull/1188) has some drawbacks because the prototype view is not a child of the collection view:
* The 'multipart' attribute is not propagated from the prototype to the collection,
* The prototype view do not use the theme from the collection.
Those 2 points are fixed by the proposed implementation and one more benefit is that the template markup might be easier to work with:
before:
```html
<div id="form_emails">
<div>
<label for="form_emails_0">0</label>
<input type="email" id="form_emails_0" name="form[emails][0]" value="a@b.com">
</div>
<script type="text/html" id="form_emails_prototype">
<div>
<label for="$$name$$">$$name$$</label>
<input type="email" id="$$name$$" name="$$name$$" value="" />
</div>
</script>
</div>
```
after:
```html
<div id="form_emails">
<div>
<label for="form_emails_0">0</label>
<input type="email" id="form_emails_0" name="form[emails][0]" value="a@b.com">
</div>
<script type="text/html" id="form_emails_prototype">
<div>
<label for="form_emails_$$name$$">$$name$$</label>
<input type="email" id="form_emails_$$name$$" name="form[emails][$$name$$]" value="" />
</div>
</script>
</div>
```
@kriswallsmith I'd like to get your feedback on this PR. thanks.
---------------------------------------------------------------------------
by stof at 2011/06/14 07:01:01 -0700
@fabpot any ETA about merging it ? Using the prototype currently is a pain to build the name. The change makes it far easier
---------------------------------------------------------------------------
by fabpot at 2011/06/14 07:09:46 -0700
The templates are much better but I'm a bit concerned that we need to add the logic into the Form class directly. That looks quite ugly. If there is no other way, I will merge it.
---------------------------------------------------------------------------
by vicb at 2011/06/14 07:14:32 -0700
I have found no better way... I am testing some minor tweaks I want to submit.
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 07:34:25 -0700
I'm not happy with the code in Form.php either... would creating a PrototypeType accomplish the same thing?
---------------------------------------------------------------------------
by vicb at 2011/06/14 07:42:07 -0700
@kriswallsmith tried and dismissed, the id and name are bad & you have to go for `render_widget(form.get('proto'))` in the template. That should be fixeable but not any better.
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 07:45:21 -0700
What do you mean the id and name are bad? If we have a distinct type for the prototype, can't we do whatever we want using buildView() and the template?
---------------------------------------------------------------------------
by vicb at 2011/06/14 07:53:31 -0700
@kriswallsmith the id would be smthg like `form_emails_$$name$$_prototype` but yes we should be able to do whatever we want but the code might end up being more complex.
I am done with the tweaks but still open to feedback on this PR.
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 08:08:21 -0700
Yes, that is the type of name I would expect.
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 08:08:33 -0700
Oops -- I mean id.
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 08:09:42 -0700
Maybe I'm confused what id you're referring to. I'll try to spend some time on this today.
---------------------------------------------------------------------------
by vicb at 2011/06/14 08:23:56 -0700
That should be the id of the `<input>`, the id of the script would be `form_emails_$$name$$_prototype_prototype` (if prototype is the name of the nested node).
I am trying to setup a branch with my code (playing with git & netbeans local history)
---------------------------------------------------------------------------
by vicb at 2011/06/14 08:46:25 -0700
@kriswallsmith https://github.com/vicb/symfony/tree/kris/proto if that can help (there are still changes in Form.php)
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 08:47:08 -0700
Thanks, I'll take a look.
---------------------------------------------------------------------------
by vicb at 2011/06/15 00:48:38 -0700
I would have expected it to be faster however `array_map` is about twice slower... reverted !
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