Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Aug 23, 2011
  1. @fabpot

    merged branch stloyd/issue_1986 (PR #2000)

    fabpot authored
    Commits
    -------
    
    c29fa9d [Form] Fix for treatment zero as empty data. Closes #1986
    
    Discussion
    ----------
    
    [Form] Fix for treatment zero as empty data. Closes #1986
    
    For more info please read #1986.
Commits on Aug 22, 2011
  1. @fabpot

    [Form] added missing DelegatingValidator registration in the Form Ext…

    fabpot authored
    …ension class (used when using the Form component outside a Symfony2 project where the validation.xml is used instead)
  2. @weaverryan
  3. @stloyd
Commits on Aug 19, 2011
  1. @fabpot

    merged branch stloyd/form_datetime_transformer (PR #1851)

    fabpot authored
    Commits
    -------
    
    d880db2 [Form] Test covered fix for invalid date (13 month/31.02.2011 etc.) send to transformer. Closes #1755
    df74f49 Patched src/Symfony/Component/Form/Extension/Core/DataTransformer/DateTimeToArrayTransformer.php to throw an exception when an invalid date is passed for transformation (e.g. 31st February)
    
    Discussion
    ----------
    
    [Form] Fix for "DateTimeToArrayTransformer" with invalid dates
    
    Hey,
    
    this is test covered fix from @mdavis1982 (closes #1755)
    
    ---------------------------------------------------------------------------
    
    by stloyd at 2011/08/16 01:31:32 -0700
    
    @fabpot Can we have this fix merged ?
  2. @fabpot

    merged branch Gregwar/email_guessing (PR #1970)

    fabpot authored
    Commits
    -------
    
    80d1718 [Fix] Email() constraints now guess as 'email' field type
    
    Discussion
    ----------
    
    [Fix] Email() constraints now guess as 'email' field type
    
    I don't know what this was set to "text"
Commits on Aug 16, 2011
  1. [Fix] Email() constraints now guess as 'email' field type

    Grégoire Passault authored
Commits on Aug 14, 2011
  1. @fabpot

    merged branch krmcbride/form-doc-fixes (PR #1959)

    fabpot authored
    Commits
    -------
    
    e3cb39d [Form] Fixed a few PHPDoc comments
    
    Discussion
    ----------
    
    [Form] Fixed a few PHPDoc comments
  2. @krmcbride
Commits on Aug 13, 2011
  1. @pylebecq
Commits on Aug 8, 2011
  1. @Gregwar
Commits on Jul 28, 2011
  1. @stloyd

    [Form] Test covered fix for invalid date (13 month/31.02.2011 etc.) s…

    stloyd authored
    …end to transformer. Closes #1755
  2. @mdavis1982 @stloyd

    Patched src/Symfony/Component/Form/Extension/Core/DataTransformer/Dat…

    mdavis1982 authored stloyd committed
    …eTimeToArrayTransformer.php to throw an exception when an invalid date is passed for transformation (e.g. 31st February)
  3. @pborreli

    [Various] Typos

    pborreli authored
Commits on Jul 22, 2011
  1. [Form] Reverted PR #1758.

    marc.weistroff authored
    Revert "[Form] CollectionType now checks for data_class parameter instead of only class."
    
    This reverts commit 2e024f8.
    
    Conflicts:
    
    	tests/Symfony/Tests/Component/Form/Extension/Core/Type/CollectionTypeTest.php
    
    Revert "[Form] Added ObjectFactoryListener. Fixes #1746."
    
    This reverts commit 0327beb.
    
    Conflicts:
    
    	tests/Symfony/Tests/Component/Form/Extension/Core/Type/CollectionTypeTest.php
  2. [Form] Collection's prototype is not not a child anymore.

    marc.weistroff authored
  3. [Form] Changed collection prototype rendering.

    marc.weistroff authored
    Based on PR 1500. It is now rendered inside an attribute of collection
    tag.
Commits on Jul 21, 2011
  1. [Form] CollectionType now checks for data_class parameter instead of …

    marc.weistroff authored
    …only class.
  2. [Form] Added ObjectFactoryListener. Fixes #1746.

    marc.weistroff authored
Commits on Jul 18, 2011
  1. @fabpot

    [Form] fixed error message

    fabpot authored
  2. @fabpot

    [Form] added a missing check (the code calls isset() and unset() and …

    fabpot authored
    …so the data must implements ArrayAccess and Traversable)
  3. @fabpot

    [Form] renamed invalid_message_template to invalid_message to be cons…

    fabpot authored
    …istent with other error message names
Commits on Jul 15, 2011
  1. @fabpot
  2. @fabpot

    [Form] removed a constraint in PropertyPath as the path can definitel…

    fabpot authored
    …y be an empty string for errors attached on the main form (when using a constraint defined with the 'validation_constraint' option)
Commits on Jul 11, 2011
  1. @fabpot

    merged branch gbirke/form_error_docs (PR #1599)

    fabpot authored
    Commits
    -------
    
    22a49f1 Better docstring for FormError constructor
    
    Discussion
    ----------
    
    Better docstring for FormError constructor
    
    Better docs for placeholder format of FormError.
  2. @vicb
Commits on Jul 9, 2011
  1. @gbirke
Commits on Jul 7, 2011
  1. @fabpot
Commits on Jul 6, 2011
  1. @mweimerskirch

    Fix error message

    mweimerskirch authored
  2. @fabpot

    merged branch stof/form_type (PR #1552)

    fabpot authored
    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.
  3. @fabpot

    merged branch kertz/date_pattern (PR #694)

    fabpot authored
    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@01ae75d) 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@e47cfb6.
    
    The other PR is [PR751](symfony/symfony#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](kertz/symfony#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.
  4. @fabpot

    [Form] removed guesser for Choice constraints

    fabpot authored
    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.
  5. @stof
Commits on Jul 5, 2011
  1. @fabpot

    merged branch vicb/form/default-validator (PR #1533)

    fabpot authored
    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
  2. @fabpot

    merged branch beberlei/ChoiceFix (PR #1531)

    fabpot authored
    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.
    symfony/symfony#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.
Something went wrong with that request. Please try again.