Commits
-------
29e4063 [Security] changed order of checks to check for more specific things first
Discussion
----------
[Security] changed order of checks
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
-------
64e9263 Updated UPDATE.md
7cf891a Renamed variable returned and used self in place of static for constants
f91f4dd Added the possibility to set cookies with the same name for different domains and paths for Symfony\Component\HttpFoundation\ResponseHeaderBag
f08eeb4 Moved managing cookies of HeaderBag in ResponseHeaderBag
Discussion
----------
[HttpFoundation] Cookies management in ResponseHeaderBag
Fixed cookies management in `Symfony\Component\HttpFoundation\HeaderBag` and `Symfony\Component\HttpFoundation\ResponseHeaderBag`
Commits
-------
26ff05bfixes#1538
Discussion
----------
fixes#1538
Constructor of Symfony\Component\Security\Acl\Domain\RoleSecurityIdentity
--------------------------------------------------------------------------------------------------------
currently it check if the argument is instance of Symfony\Component\Security\Core\Role\Role by
``if ($role instanceof Role)``
Maybe it should be changed to
``if ($role instanceof RoleInterface)``
Because if we use another Role class which implements RoleInterface
it dosen't work when we check access, it will throw a *NoAceFoundException* when vote
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
-------
2a24603 [Routing] Allow multiple `@Route` annotations with a default name on a single method (fixes#1647)
Discussion
----------
[Routing] Allow multiple `@Route` annotations with a default name
[Routing] Allow multiple `@Route` annotations with a default name on a single method (fixes#1647)
Before this change, the default name would be the same for multiple `@Route` with a default name on the same method. Then only the last declared route is active.
The defaults names are (for consecutive `@Route`s):
* former_default,
* former_default_1,
* former_name,
* former_default_2,
* ...
The FrameworkExtraBundle needs to be updated in sync with this PR: https://github.com/sensio/SensioFrameworkExtraBundle/pull/50
Commits
-------
95ca258 Fixed problems with running processes returns wrong exitcode (-1) on Linux.
Discussion
----------
#1636
Fixed problems with running processes returns wrong exitcode (-1) on Linux.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/11 11:07:42 -0700
This doesn't concern this PR specifically, but can we somehow start adding tests for this class? The process component seems like the by far most unstable code that we have.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 23:07:43 -0700
@schmittjoh: Problem is that the behavior highly depends on the platform and PHP version.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 23:14:23 -0700
@schmittjoh: By the way, we have added a bunch of tests recently (2d29a82412 (tests)/Symfony/Tests/Component/Process). Things are also "unstable" because the behavior depends on the amount of input, the amount of output, and when things happens. That means that it is also impossible to cover all possible cases reliably.
Commits
-------
d34caee merged and unified blocks `field_label` and `form_label` into `generic_label`
Discussion
----------
merged and unified blocks `field_label` and `form_label` into `generic_label`
Commits
-------
11369eb Fixed phpdoc
dbe1854 Added a AccessDeniedHttpException to wrap the AccessDeniedException.
Discussion
----------
Added a AccessDeniedHttpException to wrap the AccessDeniedException.
This is a proposal to fix#1631
It wraps the AccessDeniedException in an AccessDeniedHttpException when the firewall is not able to handle it itself. This allows getting a 403 response using the standard exception listener in this case.
Note that the app should not throw the AccessDeniedHttpException itself but keep using the AccessDeniedException to let the Security component check if the user is already fully authenticated or if it should give a chance to authenticate.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 07:10:12 -0700
For reference, I've tried something more radical some time ago here: https://github.com/symfony/symfony/pull/369.
---------------------------------------------------------------------------
by stof at 2011/07/11 07:22:07 -0700
my implementation is what @schmittjoh suggested in the comments on your PR.
Commits
-------
52fdd53 [Bridge/Twig] Add required class to labels that match required fields
Discussion
----------
[Bridge/Twig] Add required class to labels that match required fields
I have used this to simply style labels that are required with a red star behind them using this CSS:
``` css
label.required::after {
content: " *";
color: #c00;
}
```
The problem is that you can't use `input[required] + label::after` as a selector since the label is typically rendered before the input. There is no way to check for an element that is *followed by* another, only elements *following*.
Of course this CSS in particular won't work except in the latest browsers, but you could still use the `label.required` selector to add a background image and so on. I think this is a very common use case and therefore I think it'd benefit the core framework.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 01:27:49 -0700
Can you also update the PHP templates?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 01:43:33 -0700
How about namespacing these css classes, like for example "sf-form-required"?
---------------------------------------------------------------------------
by stloyd at 2011/07/05 01:50:58 -0700
I would prefer an @schmittjoh naming, or even adding ability to setup it thought options.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 01:54:36 -0700
Please, do not add more options. Prefix with `sf` is actually a good idea but people will argue that this is not a good idea because it gives too much information about the technology used to create the website (that's one of the things that came up pretty often in symfony1).
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:00:11 -0700
An option is not such a good idea imo since you likely want to have a uniform naming strategy across your entire site. How about adding a new service CssNamingStrategy?
---------------------------------------------------------------------------
by stloyd at 2011/07/05 02:01:19 -0700
Then this can be some simpler one not giving such informations i.e.: `form-label-required`, `label-required`, `framework-form-required`, `form-required` or whatever else ;-)
---------------------------------------------------------------------------
by fabpot at 2011/07/05 02:16:41 -0700
It cannot be configurable as it would potentially break bundles that come with stylesheets.
---------------------------------------------------------------------------
by stloyd at 2011/07/05 02:21:10 -0700
IMO if we decide to add this one, we could add same to `inputs/selects/etc` with `required` option.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:21:59 -0700
I think it can, consider an interface like this:
```php
interface CssNamingStrategyInterface
{
function getCssName($class);
}
```
This will give people a lot of flexibility, and it also does allow them to exclude classes which for example are provided by third-party bundles.
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 02:47:54 -0700
Wow guys, if this turns into a full blown class generator solution, I'm happy to close the PR.
"required" is not a name that's commonly used for main page elements, it's typically associated with forms, and therefore I don't see the need to make it unnecessary longer/namespaced. Similarly I don't see the need to add it to the input/select/.., because they already have an attribute, which you can very easily select as: `input[required]` in CSS. That works everywhere except IE6, but we can't build for the future on very old browsers. If you really want support for IE6, you can override the templates imo. But core should be looking forward, as it already is with HTML5, form markup, etc.
As for calling it form-label-required or label-required, again, I don't see the benefit, you can use `label.required` if you want to avoid conflicts with non-label elements having a required class, or a safer `form .required`. There are plenty of options in CSS itself, let's not make this overly complex.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:52:17 -0700
see
http://code.google.com/intl/de-DE/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
On Tue, Jul 5, 2011 at 11:47 AM, Seldaek <
reply@reply.github.com>wrote:
> Wow guys, if this turns into a full blown class generator solution, I'm
> happy to close the PR.
>
> "required" is not a name that's commonly used for main page elements, it's
> typically associated with forms, and therefore I don't see the need to make
> it unnecessary longer/namespaced. Similarly I don't see the need to add it
> to the input/select/.., because they already have an attribute, which you
> can very easily select as: `input[required]` in CSS. That works everywhere
> except IE6, but we can't build for the future on very old browsers. If you
> really want support for IE6, you can override the templates imo. But core
> should be looking forward, as it already is with HTML5, form markup, etc.
>
> As for calling it form-label-required or label-required, again, I don't see
> the benefit, you can use `label.required` if you want to avoid conflicts
> with non-label elements having a required class, or a safer `form
> .required`. There are plenty of options in CSS itself, let's not make this
> overly complex.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1519#issuecomment-1502560
>
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 03:11:50 -0700
Really? Come on, we're talking about forms, it's not like you have billions of form/input tags per page that have to be parsed by the browser when you select that. Also you don't have to select the elements, if you want true performance just use no stylesheet, your users will thank you.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 03:30:40 -0700
Your CSS selectors not only affect the performance of form elements, but of all elements that have a "required" class. Likewise, the same applies if we decide to add more classes.
Why close the door for people who care about performance? We can easily avoid this by making the css class more specific as suggested earlier. The idea with the renaming strategy is one step further and allows people to "obfuscate" which tool was used to generate the form, or do additional optimizations like shortening the css name.
---------------------------------------------------------------------------
by lenar at 2011/07/05 03:34:34 -0700
@Seldaek: Just for remark I've seen matrix forms spanning multiple screenfuls horizontally and vertically
containing tens of thousands inputs. Not pretty, but they do exist. Basically "poor" man's/company's excel
emulation or something.
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 04:19:13 -0700
@schmittjoh, @lenar: We're catering to the most common use case, for which this will be more than fast enough. Small/medium scale websites don't have to optimize on CSS rules parsing, they usually have much bigger issues to deal with. If you really care about it, overriding the block to remove the class is just as easy as it was to for me to add it, but IMO this is the edge case.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 05:37:19 -0700
IMO Symfony should follow best practices by encouraging to use class selectors, and not tag selectors for the reasons explained on the page I linked.
Anyway, I think everybody made his points. Time for @fabpot to make a decision :)
Commits
-------
22a49f1 Better docstring for FormError constructor
Discussion
----------
Better docstring for FormError constructor
Better docs for placeholder format of FormError.
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
-------
f7d0f65 RFC2616 changes
b9a218a [HttpFoundation] set Content-Length header to the length of content
Discussion
----------
[HttpFoundation] set Content-Length header to the length of content
I can't think of why this could be bad but if somebody knows please chime in.
The good thing is that with this change keepalive will work out of the box.
---------------------------------------------------------------------------
by Seldaek at 2011/07/06 05:34:51 -0700
That sounds like a great change. I think it might explain/fix the issues I've encountered with AppCache on my production box. Never had time to look into it, but IIRC I noticed the missing Content-Length, and it seemed to load forever.
---------------------------------------------------------------------------
by fabpot at 2011/07/06 06:46:50 -0700
The `Content-Length` is automatically added by servers like Apache. Moreover, sometimes, you should not add it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
---------------------------------------------------------------------------
by lenar at 2011/07/06 07:54:45 -0700
It is not added automatically by default. Yes, in case of Apache it is actually added if deflate module is enabled and if that module decides to compress the content (decision based on content-type).
About RFC2616: I will read it and add changes to this PR if applicable.
---------------------------------------------------------------------------
by fabpot at 2011/07/06 08:38:14 -0700
e943fde2ef
---------------------------------------------------------------------------
by Seldaek at 2011/07/06 08:45:22 -0700
@lenar all you have to do is skip setting the Content-Length for `1xx`, `204`, and `304` responses I believe.
---------------------------------------------------------------------------
by Seldaek at 2011/07/06 08:46:54 -0700
But this should maybe be done in sendHeaders() à la `fixContentType`, because you can't be sure about the statusCode before that.
---------------------------------------------------------------------------
by lenar at 2011/07/06 13:55:33 -0700
I propose this based on what I read and understood from RFC2616.
---------------------------------------------------------------------------
by mheleniak at 2011/07/10 03:57:26 -0700
+1
Commits
-------
e6a2d76 delay resolving values of extensions config until all files are loaded
Discussion
----------
[DependencyInjection] Delay resolving values of extensions' config until all files are loaded
This addresses #1598.
This delays resolving of extensions' configuration until all files are loaded. Without this, overriding parameters do not work for extensions.
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
-------
9714cfc Fixes fatal error when intl module is not installed.
Discussion
----------
Session instantiation breaks with Fatal error if intl module is not installed.
A check for class_exists in setPhpDefaultLocale() fixes this, though I got the feeling it should be resolved with a proxy or subscriber object; setPhpDefaultLocale feels like a hack now.
---------------------------------------------------------------------------
by stealth35 at 2011/07/10 06:32:43 -0700
Locale::setDefault don't throw any exception
Maybe just :
```php
if (class_exists('Locale', false)) {
return \Locale::setDefault($this->locale);
} else {
return false;
}
```
Commits
-------
08b4219 [DoctrineBridge] Issue #1376 - Unique Validator does not work with null values
Discussion
----------
Issue1376
[DoctrineBridge] Issue #1376 - Unique Validator does not work with null values
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
-------
df57e0f [Validator] Added strict option to ChoiceConstraint.
Discussion
----------
[Validator] Added strict option to ChoiceConstraint.
By default, ChoiceValidator was ensuring strict type when checking if value is present in choices. This behavior is a problem when you want to validate against integer values. As all data you will receive from a request will be typed as a string, you won't be able to validate these numeric values.
This patch solves this.
In order for being nice to developers, I've set "strict" to false by default.
Commits
-------
6c736c9 Fix RedirectResponse HTML indentation and constructor phpDoc
Discussion
----------
Fix RedirectResponse HTML indentation and constructor phpDoc
Removes extra indents from the redirection response content.
Commits
-------
ac1448f [Routing] Revert to rawurlencode + whitelisting of '/'
Discussion
----------
[Routing] Revert to rawurlencode + whitelisting of '/'
After more discussion on 761724ae57 - sorry you merged too fast for once ;)
Commits
-------
6786e81 [HttpFoundation] code factorization in UploadedFile
Discussion
----------
[HttpFoundation] code factorization in UploadedFile
As both #1542 and #1544 have been merged.
Problem with fgets is that false means two things: an error or the end of the stream.
That's ok for STDIN, but it becomes a problem when using another stream (in a unit test for instance).
This change allows for more flexibility if the developer wants to flush
the Response content early (the drawback being that Response listeners
won't be able to tweak the HTTP headers anymore).
There is another benefit: avoid the infamous
"Fatal error: Exception thrown without a stack frame in Unknown on line 0".
Here is a small scenario when this can happen (thanks dtee for identifying this issue):
* Call flush() in controller to output html early, then throw exception
* ExceptionHandler triggers handle() function and return new Response object to output...
* Because the header is sent (flush() call in Controller), php's E_WARNING error get raised, which gets handled by ErrorHandler->handle() and it throws new ErrorException()
* PHP fatals to prevent Exception loop: "Fatal error: Exception thrown without a stack frame in Unknown on line 0"
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
-------
ef022c0 Removed the magical guessing of the type name to avoid WTF issues
Discussion
----------
Removed the magical guessing of the type name to avoid WTF issues
As discussed on IRC, this removes the magical method to avoid breaking the user-land code by reusing the same name than another type which overrides it. This makes the user aware that a type should have a name as they now have to implement the method themselves.
---------------------------------------------------------------------------
by jalliot at 2011/07/06 05:35:30 -0700
Doc and generator should be modified as well if it's merged.
Commits
-------
133169f Better exception message for extension in XmlFileLoader
Discussion
----------
Better exception message for XmlFileLoader
Include namespace that has been looked for an registered namespaces in the exception message to ease debugging.
Commits
-------
fa20b51 [Console] refactored definition printer
e49d61f [Console] fixed console help printing expectations
Discussion
----------
[Console] definitions printing fix
Before this change, console component printed definitions as:
``` bash
Arguments:
features Feature(s) to run. Could be a dir (features/),
a feature (*.feature) or a scenario at specific line
(*.feature:10).
Options:
--config (-c) Specify external configuration file to load. behat.yml or config/behat.yml will be used by default.
--profile (-p) Specify configuration profile to use. Define profiles in config file (--config).
--init Create features directory structure.
--format (-f) How to format features. pretty is default. Available formats are
- pretty
- progress
- html
- junit
--out Write formatter output to a file/directory instead of STDOUT (output_path).
--colors Force Behat to use ANSI color in the output.
--no-colors Do not use ANSI color in the output.
--no-time Hide time in output.
--lang Print formatter output in particular language.
--no-paths Do not print the definition path with the steps.
--no-snippets Do not print snippets for undefined steps.
--no-multiline No multiline arguments in output.
--expand Expand Scenario Outline Tables in output.
--story-syntax Print *.feature example in specified language (--lang).
--definitions Print available step definitions in specified language (--lang).
--name Only execute the feature elements (features or scenarios) which match part of the given name or regex.
```
As you might see, indentation is totally broken (also notice how it prints multiline descriptions in argument and --format option).
This PR makes output looks like this:
``` bash
Arguments:
features Feature(s) to run. Could be a dir (features/),
a feature (*.feature) or a scenario at specific line
(*.feature:10).
Options:
--config (-c) Specify external configuration file to load. behat.yml or config/behat.yml will be used by default.
--profile (-p) Specify configuration profile to use. Define profiles in config file (--config).
--init Create features directory structure.
--format (-f) How to format features. pretty is default. Available formats are
- pretty
- progress
- html
- junit
--out Write formatter output to a file/directory instead of STDOUT (output_path).
--colors Force Behat to use ANSI color in the output.
--no-colors Do not use ANSI color in the output.
--no-time Hide time in output.
--lang Print formatter output in particular language.
--no-paths Do not print the definition path with the steps.
--no-snippets Do not print snippets for undefined steps.
--no-multiline No multiline arguments in output.
--expand Expand Scenario Outline Tables in output.
--story-syntax Print *.feature example in specified language (--lang).
--definitions Print available step definitions in specified language (--lang).
--name Only execute the feature elements (features or scenarios) which match part of the given name or regex.
```
Commits
-------
d08a688 [Form] Fixed CS
954bdb5 [Form] Updated DateTimeType to accept a custom date pattern for the DateType child * Added a test also about this change
e7e744f [Form] Synced changes in this branch with current Symfony master branch
436cb95 [Form] Changed to a CreateException when the 'format' option is invalid * Updated DateTypeTest also
0045ffe [Form] Added tests to check that the date format option is validated correctly * Format option must be either a IntlDateFormatter constants (FULL, LONG, MEDIUM, SHORT) or a string
a815232 [Form] The IntlDateFormatter pattern can now be passed via the format option * Also changed the default value of the calendar paramter to \IntlDateFormatter:GREGORIAN in DateTimeToLocalizedStringTransformer which is the same as the default value in StubIntlDateFormatter
58f869a [Form] Synced custom pattern tests with master branch
c20edde [Form] Added some tests * Tests to check if the pattern option is handled correctly by DateType * Tests to check if the pattern parameter is handled correctly by DateTimeToLocalizedStringTransformer
52a1e1d moved date_pattern to IntlDateFormatter
dd104bc added code to use custom date_pattern
Discussion
----------
[Form] Added code to use custom date_pattern
Current DateType doesn't make use of the `date_pattern` option. Added code to use the custom `date_pattern` if provided.
---------------------------------------------------------------------------
by maoueh at 2011/05/02 21:52:37 -0700
You should also pass the pattern option to the DateTimeToLocalizedStringTransformer so the pattern is taken in consideration when converting from and to localized string. You can check the commit I did on my repository (maoueh/symfony@01ae75dd84) which do the same as yours for the DateType but also includes the modification needed by the DateTimeToLocalizedStringTransformer class.
Not sure if there is more work needed to fully support the pattern option. Moreover, I did not run the tests to check if everything pass correctly. It would also be a good idea to add some tests to check that the date_pattern is working as expected.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/02 22:02:14 -0700
There is also a problem with the regex, but this is not regarding the pattern option. If you set the 'format' option to 0, it returns the IntlDateFormatter::FULL but it does not pass the regex because there is first EEEE in the standard pattern so it comes on the fallback pattern year month day
---------------------------------------------------------------------------
by kertz at 2011/05/02 23:36:05 -0700
Thanks for your suggestions @maoueh and @dot-i-fy, I will check them.
I found the `date_pattern` doesn't work when using text widget. I will try to fix this.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 00:02:45 -0700
Here the regex I use now and working with IntlDateFormatter::FULL
https://gist.github.com/952929
---------------------------------------------------------------------------
by maoueh at 2011/05/03 07:13:01 -0700
@kertz: It is working for me using the text widget on my development machine. Don't know what is the problem on our side but it is working correctly for me. I'm willing to help track this problem if you want. Just let me know.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 07:57:34 -0700
@kertz : It is also working for me, we just have to pay attention about the format to be used in the text input regarding IntlDateFormatter.
---------------------------------------------------------------------------
by kertz at 2011/05/03 11:15:23 -0700
Ah well I guess I screwed up the whole commit log!
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 11:19:08 -0700
wow !
---------------------------------------------------------------------------
by maoueh at 2011/05/03 11:23:51 -0700
Hell yeah! :) You should do a rebase the next time instead of merging Symfony master branch into yours:
`git rebase symfony/master date_pattern` and when you need to push your changes to your repository, do `git push -f origin date_pattern`. This way, it will be easier for the core team to handle the merge process.
Since @dot-i-fy opened a pull request for fixing the same issue as here, maybe it would be a good idea to close this PR?
---------------------------------------------------------------------------
by kertz at 2011/05/03 11:33:34 -0700
Well, it's done. I just pushed it a little earlier that I should have! Well I didn't know that @dot-i-fy opened a PR, where is it? This patch currently works for me.
Regarding the change in regex, well I think it should also have a ChoiceList for week days, otherwise it's not useful. Probably that alone can be a separate PR.
---------------------------------------------------------------------------
by maoueh at 2011/05/03 11:46:09 -0700
Yep it is much better now :) I think it would be a good idea to remove this commit from your PR kertz/symfony@e47cfb6d49.
The other PR is [PR751](https://github.com/symfony/symfony/pull/751). Maybe @dot-i-fy could change is PR so it will only be about the regex? In both cases, you should coordinate with each other I think.
Thanks for merging the changes I made to the DateTimeToLocalizedStringTransformer class.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 12:00:06 -0700
Yeah, I will modify my commit to take only the regex in account.
Would someone work with me on the TimeType ? The pattern is also not working there but it looks like a little bit more complicated!
Thanks
---------------------------------------------------------------------------
by kertz at 2011/05/03 12:02:18 -0700
Thanks for the changes in DateTimeToLocalizedStringTransformer.
Is it really necessary to remove the initial commit?
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 12:06:41 -0700
What does it mean CS ?
---------------------------------------------------------------------------
by maoueh at 2011/05/03 12:08:44 -0700
@dot-i-fy: It means Code Style, the comma is not placed correctly
---------------------------------------------------------------------------
by kertz at 2011/05/03 12:11:24 -0700
`Coding Standards` seems right :) http://symfony.com/doc/2.0/contributing/code/standards.html
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 12:11:27 -0700
ah ok, thx
---------------------------------------------------------------------------
by maoueh at 2011/05/03 12:12:10 -0700
@kertz: I don't think it is strictly necessary to remove this commit. But I think it is a good idea since you kinda reverted it with some changes in a later commit. The core team might ask you to remove it. So leave it for now, and change it if they ask you to do so.
Hehe right, Coding Standards looks way better :)
---------------------------------------------------------------------------
by maoueh at 2011/05/03 12:30:00 -0700
@dot-i-fy: I will check later in the evening what can be done about the pattern in the TimeType class. I'm also planning on adding some tests about this PR. If I do so, I will send a PR to your repository @kertz so you will be able to add the tests to this PR.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/03 13:04:35 -0700
I had some problems with PHPUnit, seems to be ok now. Another problem, damned, APC is showing in my browser when in app_dev.php, not in prod. Any idea ? Can't get html output in dev env.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/04 00:43:46 -0700
@RapotOR : Are you talking about the dateType method in IntlDateFormatter ? If no can you make a snippet in gist with an example ?
If yes ...The option "format" already allows an IntlDateFormatter input, you can either set a \IntlDateFormatter::MEDIUM for example or an integer representing the dateType to use (0 -> full, 1 -> long, ... ).
The problem we are reveling here is the pattern based off the dateFormat option :
the $formatter look for Locale -> then for format option and based off these options he generate a pattern who can be different regarding the Locale. For example, for me I have my locale in php set to fr_BE, so my dates are always d-m-Y formatted but if I want to modify that it is momently not possible.
Grtz
---------------------------------------------------------------------------
by RapotOR at 2011/05/04 00:57:03 -0700
@dot-i-fy : my thought was more about having a full control of IntlDateFormatter from outside; instead of defining every variables. It is more like a DI way... especially if you have more than one DateType field!
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/04 01:11:21 -0700
Oh so, it may be indeed a nice way to follow. Don't hesitate to submit your code suggestions.
But I think that if we go deeper in the core modifications, it is maybe a solution to take the $formatter out of the dateType class and put it in a own class and call it from the dateType class ???@}#
---------------------------------------------------------------------------
by maoueh at 2011/05/05 08:22:40 -0700
@mweimerskirch: Maybe it would be better to rename your option html_pattern? Since the pattern is not strictly associated to a date type, it would be a better name in my opinion if it was named html_pattern or html5_pattern?
I think it would lead to more misunderstandings if we had a date_pattern and a pattern option. In both cases, I agree totally that one or the other needs a renaming. Moreover, if we change the pattern option in the date type, I think the format option should be changed also to date_format.
What do you think?
---------------------------------------------------------------------------
by kertz at 2011/05/05 23:58:21 -0700
@mweimerskirch
I too think when we specify `pattern` in `DateType` everyone expects it to be the date pattern. So maybe renaming the HTML5 pattern to `html_pattern` would be more appropriate?
---------------------------------------------------------------------------
by bschussek at 2011/05/18 12:20:56 -0700
Looks good. Why don't we reuse the "format" option for this? If "format" is not one of the predefined constants, we could treat it as a custom date format.
---------------------------------------------------------------------------
by maoueh at 2011/05/18 12:28:22 -0700
@bschussek: I think it is a good idea indeed. When I first played with forms, I thought that the purpose of the format option was exactly for this but I soon realized it wasn't. I'm +1 for this.
@kertz: Let me know if you don't have time to do this switch, I will gladly submit the changes to you own repo if we agree to use "format" option instead of the "pattern" one.
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/18 12:33:33 -0700
``format`` and ``pattern`` options are related to the IntlDateFormatter, I also agree with you but we have to keep in mind that we will loose the symmetry with the IntlDateFormatter class.
---------------------------------------------------------------------------
by bschussek at 2011/05/18 13:39:07 -0700
I think we can safely add this level of abstraction.
---------------------------------------------------------------------------
by kertz at 2011/05/18 20:29:11 -0700
@maoueh Would be great if you can make the changes :)
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/19 09:09:41 -0700
@bschussek : I saw you removed pattern option, what are further intentions ?
---------------------------------------------------------------------------
by maoueh at 2011/05/19 09:42:40 -0700
@kertz: I will do the changes needed tomorrow as I have some spare times. You will need to sync your branch with current master or I will need to send another PR since @bschussek removed the pattern option which will cause bad conflicts with this implementation.
---------------------------------------------------------------------------
by kertz at 2011/05/20 06:45:22 -0700
@maoueh I've merged the changes.
---------------------------------------------------------------------------
by kertz at 2011/05/20 07:11:36 -0700
@maoueh I just removed a couple of commits from the log. Seems like the tests you committed are now missing from the PR. Can you please send the tests once again? Sorry about that.
---------------------------------------------------------------------------
by maoueh at 2011/05/20 09:03:52 -0700
@kertz: I will resend them along with the code modifications to use `format` instead of `pattern`.
---------------------------------------------------------------------------
by maoueh at 2011/05/20 19:11:28 -0700
I did the changes to make it possible to pass a custom pattern via the format option. I sent a PR on @kertz repository [here](https://github.com/kertz/symfony/pull/2) that will be merge eventually in this PR.
I have two small questions about it. First, since format option can now be a string, the allowed values for the option `format` have been removed from the array returned by `getAllowedOptionValues`. The check is done instead in the method `buildForm` directly. The 'format' option can be either one of the `IntlDateFormatter` constants (FULL, LONG, MEDIUM, or SHORT) or a string. If those conditions are not respected, a `FormException` is thrown. Is this correct?
When the `format` option is a custom pattern, the IntlDateFormatter needs a valid format even if it will not be used. So I retrieved the default format option by using the `getDefaultOptions` method. Is this correct or should I specify the default value directly:
this (specify directly):
$format = \IntlDateFormatter::MEDIUM;
instead of (use predefined defaults):
$defaultOptions = $this->getDefaultOptions($options);
$format = $defaultOptions['format'];
Also added more tests to verify that the format option is validated correctly and updated previous ones.
Regards,
Matt
---------------------------------------------------------------------------
by kertz at 2011/05/20 20:38:32 -0700
Merged the changes. I have not tested this yet... Thanks @maoueh :)
---------------------------------------------------------------------------
by dot-i-fy at 2011/05/20 22:48:47 -0700
nice job @maoueh
---------------------------------------------------------------------------
by mprizmic at 2011/06/16 14:06:47 -0700
what do you think about
$pattern = $form->getAttribute('pattern');
instead of
$pattern = $form->getAttribute('formatter')->getPattern();
in line 96 of
symfony/component/form/extension/core/type/datetype.php
---------------------------------------------------------------------------
by maoueh at 2011/06/16 14:40:37 -0700
It is simpler to use the pattern of the formatter directly I think. The reason is that if the option to change the format is null, the default pattern of the formatter will be available and will be the right pattern to use. If the option is set, we modify the formatter before hand so getting the pattern from it will return the custom pattern we have set in the options.
So in both cases, no conditional is required to verify if it is set or not when retrieving the pattern from the formatter. Moreover, I think the pattern must be set as an attribute of the form for your suggestion to work correctly which is not the case right now.
Regards,
Matt
---------------------------------------------------------------------------
by stloyd at 2011/07/05 13:41:36 -0700
@fabpot What we do with that ? I have tried to rebase it with master, but my (Windows) git always gets insane and this ends up with unfixable error. This feature __should__ be in Symfony2 before final. Should I start work on it from "none" ?
---------------------------------------------------------------------------
by fabpot at 2011/07/06 05:44:26 -0700
@stloyd: I need to review the patch first.
The guesser has been removed as the constraints only knows
about the valid keys. But to be able to create the Type automatically,
we also need the values.
Commits
-------
3df5ec3 [HttpKernel] Add support for 'upload_max_filesize' ini directive in the Client
Discussion
----------
[HttpKernel] Add support for 'upload_max_filesize' ini directive
[HttpKernel] Add support for 'upload_max_filesize' ini directive in the Client
__This PR depends on #1542__
This PR prevent the SW Client from uploading files larger than the limit set in php.ini to closer mimic a real browser usage.
If both PR eventually gets merge `static protected function getMaxUploadFilesize()` should probably be factorized to the UploadedFile class.
---------------------------------------------------------------------------
by stloyd at 2011/07/05 13:35:06 -0700
+1 for both, I just have found similar "wtf" issues with "empty" `upload_max_filesize`.
---------------------------------------------------------------------------
by oscarballadares at 2011/07/05 15:13:23 -0700
I have opened an issue related to UPLOAD_ERR_INI_SIZE. There was no way to handle this exception.
Can you confirm please?
If this is the case I will close the issue I opened.
---------------------------------------------------------------------------
by vicb at 2011/07/05 23:04:08 -0700
@oscarballadares the PR you are looking for is most probably #1542 - which you should see in the message thread of your submitted issue.
The best would be for you to verify that PR #1542 fixes your issue and provide some feedback so that the issue can be close but only when the PR gets merged (if it fixes the issue).
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
-------
4c6e177 [Form] Fix the default validator
Discussion
----------
[Form] Fix the default validator
When php.ini has an empty value for post_max_size
`post_max_size =`
see http://fr2.php.net/manual/en/function.ini-get.php
post_max_size can not be false as it has a default value
Commits
-------
03fee4f Fix permissions
431460f [Form] Remove choice or choice_list requirement as the following conditions already check enough and this condition prevents empty select forms (populated by ajax for example)
Discussion
----------
[Form] Choice fix
[Form] Remove choice or choice_list requirement as the following conditions already check enough and this condition prevents empty select forms (populated by ajax for example)
---------------------------------------------------------------------------
by stloyd at 2011/07/05 06:26:36 -0700
You should revert permission changes.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 06:28:14 -0700
Why not replacing `if (!$options['choices'] && !$options['choice_list']) {` by `if (!isset($options['choices']) && !isset($options['choice_list'])) { `?
---------------------------------------------------------------------------
by beberlei at 2011/07/05 06:35:50 -0700
gnaa permission changes, i cant seem to configure my machine such that it does not do it, i have to do this on a per repository basis, very annoying.
@fabpot isset() is already guaranteed because these two options are in the defaults.
---------------------------------------------------------------------------
by beberlei at 2011/07/05 06:39:43 -0700
Fixed the permissions
---------------------------------------------------------------------------
by stof at 2011/07/05 06:48:37 -0700
@beberlei Can't you fix it in the global git config ?
---------------------------------------------------------------------------
by webda2l at 2011/07/05 09:48:58 -0700
I met the same problem this afternoon and vote for the isset solution. Better than nothing and work for me.
https://github.com/symfony/symfony/pull/1539
---------------------------------------------------------------------------
by stof at 2011/07/05 09:50:09 -0700
@webda2l why is a check that always return true better than nothing ? It adds overhead without adding any value in the code.
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
-------
511a9a1 Edited src/Symfony/Component/Console/Helper/DialogHelper.php via GitHub
Discussion
----------
EOF triggers infinite loop in console dialog helper
* fix by throwing an exception when fgets() fails
* Also fixes "0" returning a default answer instead of "0"
---------------------------------------------------------------------------
by lenar at 2011/07/05 00:26:02 -0700
Fixes#1521.
