Commits
-------
164aea4 [Security] Add tests for the channel listener
d51cbc0 [Security] Remove useless attribute in basic authentication listener & test it
91e6dc9 [Security] Add tests for the anonymous authentication listener
3c2affb [Security] Update access listener constructor's prototype and add tests
81afd77 [Security] Add tests for the firewall map
aa6ae33 [Security] Remove useless attribute & var in firewall
Discussion
----------
Test security
---------------------------------------------------------------------------
by lsmith77 at 2011/06/29 13:41:07 -0700
@schmittjoh is probably the person to review this change ..
Commits
-------
49af102 Throwing FormNotBoundException when calling form isValid
Discussion
----------
Throwing FormNotBoundException when calling form isValid
---------------------------------------------------------------------------
by Seldaek at 2011/06/28 12:20:04 -0700
I'd have made that a `\LogicException`, but that's just me hating on custom exceptions. Otherwise as said on IRC, 👍.
---------------------------------------------------------------------------
by stloyd at 2011/06/28 12:27:27 -0700
+1 but IMO `FormException` would be here good enough.
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
-------
06c3712 [Form csrf] FileTypeCsrdExtension is not required any more (as FileType now extends FieldType)
Discussion
----------
[Form csrf] FileTypeCsrdExtension is not required any more
FileType now extends FieldType.
Commits
-------
418d6a0 [Routing] Fix syntax error when dumping routes with single quotes in the requirements or pattern
2b5e22d [Routing] Fix ApacheDumper when a space appears in a default value
6c7f484 [Routing] Fix dumper so it doesn't print trailing whitespace
761724a [Routing] Adjust urlescaping rules, fixes#752
Discussion
----------
[Router] Bunch o' Fixes
The first commit changes the escaping rule to fix issues I had previously, and #752 as well, here's from the full commit message:
Only + and % are now encoded in generated routes, since they are the only characters that, if not encoded, could cause problems/conflicts when decoded. Namely + turns into a space, and % followed by numbers could do funky things.
The matcher decodes everything which works since nothing will have %NN without being escaped, and + are escaped as well.
Second commit is just a test fix for the first
Third and fourth are simply dumper escaping issues, nothing to argue about.
Note that all changes have had test cases added, and I spent a few hours torturing/testing all this stuff with both Apache and PHP dumpers, in many browsers, and with URLs as wonky as `/%01%02%03%04%05%06%07%08%0E%0F%10%11%12%13%14%15%16%17%18%19%1A%1B%1C%1D%1E%1F%20!%22$%25&%27%28%29*+,-./0123456789:;%3C=%3E@ABCDEFGHIJKLMNOPQRSTUVWXYZ%5B%5D%5E_%60abcdefghijklmnopqrstuvwxyz%7B|%7D~/baz` which essentially represent the 1-255 char range minus ? and #.
The only issues I really encountered after all the patches were applied is that Apache refuses to match `%22` (= `"`) and `*` in a url. I guess it's just because they're not allowed chars in windows paths, but | and < > works fine though. Anyway this works with the PHP dumper, and it didn't work either without my patches so it's not like I broke it, I'm just saying for the record.
Commits
-------
1cc1027 added @Annotation to UniqueEntity
ee22c5d added a note to update file
efcb435 updated to doctrine changes
Discussion
----------
updated to doctrine changes
---------------------------------------------------------------------------
by excelwebzone at 2011/06/30 06:29:23 -0700
Should also be implemented to the Route class and to all SensioFrameworkExtraBundle annotation classes
* TimeType:
- seconds are no longer populated if "with_seconds" = false
- "widget = text" is now properly rendered (closes#1480)
* DateTimeToStringTransformer:
- fixed using not default "format" (probably fix#1183)
* DateType, DateTimeType, TimeType:
- fixed "input = datetime" and test covered
- a bit changed readability
Commits
-------
4e7b16f Added "trans" Twig filters to labels in the "widget_choice_options" block
Discussion
----------
Missing "trans" Twig filters for labels in the "widget_choice_options" block
Added "trans" Twig filters to labels in the "widget_choice_options" block.
A quick fix for a quick need, there might be other missing trans filters remaining.
Only + and % are now encoded in generated routes, since they are the only characters that, if not encoded, could cause problems/conflicts when decoded. Namely + turns into a space, and % followed by numbers could do funky things.
The matcher decodes everything which works since nothing will have %NN without being escaped, and + are escaped as well.
Commits
-------
f4c7333 Fix populating seconds when option "with_seconds" is set to false
Discussion
----------
[Form][DateTimeType] Fix invalid data when "with_seconds" = false
Fix populating seconds when option `with_seconds` is set to `false`.
Commits
-------
e80ce57 [HttpFoundation] Add REQUEST_TIME by default
Discussion
----------
[HttpFoundation] Add REQUEST_TIME by default
Without this the getting the REQUEST_TIME from the Request in tests is breaking.
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
-------
6b72cda removed whitespace
282a493 moved the constant from the interface back into the class
7ec7fbe fixed inteface name
9a82924 [Console] Extract the OutputFormatter's regular expression into the inteface.
Discussion
----------
[Console] Expose the OutputFormatter's regular expression
In my ConsoleBundle(https://github.com/CoreSphere/ConsoleBundle) I needed to decorate the OutputFormatter to enable html escaping while allow to apply styles.
For that I need to reuse the regular expression used in the original OutputFormatter. I think it would be cleaner exposing it than duplicating it.
(https://github.com/CoreSphere/ConsoleBundle/blob/master/Formatter/HtmlOutputFormatterDecorator.php#L64)
---------------------------------------------------------------------------
by fabpot at 2011/06/23 12:24:43 -0700
OutputFormatter is just one implementation of the interface, so the constant cannot be defined in the interface.
---------------------------------------------------------------------------
by laszlokorte at 2011/06/23 13:01:46 -0700
I made the false assumption all Formatters would use the same syntax for defining style. I moved it back into the class.
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
-------
a664a60 [Translation] support phar archives by XLIFF loader
Discussion
----------
[Translation] support phar archives by XLIFF loader
Support XLIFF translation files usage from phar package.
---------------------------------------------------------------------------
by fabpot at 2011/06/19 03:06:50 -0700
phar support is complex as not everything in PHP supports it. This patch only solves one area where phar is not supported. So, we need a solution that makes the entire framework phar-compatible, which is far from easy (realpath for instance cannot be used anywhere). So, I'm closing this PR and let's revisit the global phar support for 2.1.
---------------------------------------------------------------------------
by everzet at 2011/06/19 04:47:49 -0700
I'm not trying to package Symfony2 into phar :-) As it's indeed, very complex task even for 2.1. What i'm trying to do - i'm trying to package Behat in *.phar. And the only thing that blocks it - this PR. So, i'm not interested in full-stack phar support for entire Symfony2 framework right now, but as Symfony2 Components were created as stand-alone libs, this PR is enough to make Translation component itself supporting phar packaging. I use Translation component and XLIFF translations in Behat heavily and this PR gives me ability to create fully-working behat.phar package (tested).
Also, this PR doesn't breaks anything and even more - it's exactly the same piece of code, that we have in DependencyInjection component now: https://github.com/symfony/DependencyInjection/blob/master/Loader/XmlFileLoader.php#L327.
I'll be happy to work on phar support for 2.1. But for now, i can't see real reasons why Translation component can't already support it ;-)
Commits
-------
7db0b95 [HttpKernel] Removed unnecessary strtoupper
0891c57 [HttpKernel] Added test
1350645 [HttpKernel] Uppercased a few http methods
05c9906 [HttpKernel] Suppress response content for 304 responses out of the cache
Discussion
----------
HttpCache changes for 304 responses
Fixes#1413
To get the proper status for the Process, it needs to be terminated.
Sometimes, this is not the case when we call proc_get_status, so this
patch waits up to 1 sec to get the right information.
Commits
-------
d49e306 [DomCrawler] Fixed handling of relative query strings as links
a4451b4 [DomCrawler] Added tests for links starting with ?foo
Discussion
----------
[DomCrawler] Fixed handling of relative query strings as links
The link object concatenates links containing only a query string to the current URI. This shouldn't happen if the current URI already contains a query string.
This PR fixes the incorrect behavior (tests included).
Commits
-------
7783a05 Removed unused code from DateType Additional tests for ChoiceType and DateType based code
cdd39ac Added ability to set "empty_value" for `DateTimeType`, `DateType` and `TimeType` Additional tests covering added code
af4a7d7 More tests and more compatible code, with some suggestions from @helmer
527b738 Test covered version of fix for issue #1336
Discussion
----------
[Form] Added ability to set "empty_value" for choice list
Hey,
This PR is similar to #1336, but this one is fully test covered and have few change in behavior:
- if choice field is not set as non-required, `empty_value` is not added automaticly,
- also `empty_value` is not set if field have option `multiple` or `expanded`,
- `empty_value` for `DateType` and `TimeType` can be set "global" or per field, i.e.:
```
$builder->add('date', 'choice', array('required' => false, 'empty_value' => array('day' => 'Choose day')));
```
- `DateType` and `TimeType` code was cleaned a bit,
- added missing option to set up choice list as required when using PHP templates
---------------------------------------------------------------------------
by stloyd at 2011/06/20 04:55:45 -0700
@fabpot I'm just not sure is that change with removing "auto-adding" of `empty_value` is good (probably BC)
---------------------------------------------------------------------------
by lenar at 2011/06/20 05:24:02 -0700
Now this is a really nice way to hijack work done by others. Really encourages newcomers. Gratz!
---------------------------------------------------------------------------
by fabpot at 2011/06/20 05:57:40 -0700
@lenar: if the code in this PR is yours (at least partly), I'm not going to merge it. @stloyd, can you clarify this issue with @lenar? Thanks.
---------------------------------------------------------------------------
by lenar at 2011/06/20 06:21:11 -0700
It's @helmer's mostly, not mine, but the issue stays.
---------------------------------------------------------------------------
by fabpot at 2011/06/20 06:26:15 -0700
No matter who the code belongs to, Git allows us to keep track of all contributors. So, we need to do our best to not loose any code ownership.
---------------------------------------------------------------------------
by helmer at 2011/06/20 06:58:03 -0700
I do not care much for ownership, just that this kind of cooperation (or lack thereof) is kind of exhausting. Closed#1336.
---------------------------------------------------------------------------
by stloyd at 2011/06/20 07:47:53 -0700
@fabpot, @lenar: This PR is inspired by #1336, made by @helmer, but after looking at his code and talking with him, we cant (IMO) get an consensus. So I wrote this PR as an another way to fix issue described in #1336.
__Summary__: I don't think this one is better than fix at #1336, it's more like another approach to fix that issue.
---------------------------------------------------------------------------
by helmer at 2011/06/20 08:15:59 -0700
@stloyd: I actually think your variant is better, so good job there, thanks.
It just ain't nice to:
1) Comment on my changes being useless due to lack of tests
2) Writing brand new testsuite from your perspective that "proves" my approach is "wrong" (while ignoring my answers, why I did something precisely like I did, which I did in sync with @fabpot comments on his first attempt to improve the issue)
3) Saying my PR is broken because your new tests against it fail
4) Changing functionality to "fix" something that was not really broken
Other than that, I wanted to contribute a few lines to improve something relatively simple, and it ended up in a huge mess with more lost hours than I planned to spend on it.
On the bright side, we ended up with something good (:
---------------------------------------------------------------------------
by stloyd at 2011/06/20 08:32:30 -0700
@helmer: 1) & 2) Sorry for that "bad language", but you get me wrong a bit. Tests was written for code in master (there was no problem to change them to work with your POV). 3) Same as before, you can adopt tests easily, but never mind. Maybe later we could cooperate better ;-)
About 4) I mentioned it in description of this PR and that was point I was disagreeing with you (also about how "default" options are adopted in fields) :-)
Commits
-------
5d46e63 [Form] Add the FormHelper configuration
a43fad4 [Form] Improve unit tests for rendering
1cb2129 [FrameworkBundle][Form] Adding a cache to FormHelper::lookupTemplate()
f39ce67 [Form][FrameworkBundle] PHP theming
Discussion
----------
[2.1] RFC [Form] Php theming
This PR implements theming support for the php engine.
It works similarly as the twig theming with themes being folders and blocks being individual files.
There are probably a few things to tune before this can get merged:
### Theme naming
The current format is "\<Bundle\>:\<Controller\>" i.e. "FrameworkBundle:Form".
Is this ok or could you imagine something better ?
### Div and Table theme folders
Currently "FrameworkBundle\\Resources\\views\\Form" and "FrameworkBundle\\Resources\\views\\FormTable"
Is this ok or anything better ?
### Form helper configuration
I am not sure if the configuration is at the best possible location:
```
framework:
templating:
form:
resources: [themeA, themeB]
```
Any better idea ?
There is a [thread on the ml](http://groups.google.com/group/symfony-devs/browse_thread/thread/9b3f131fe116b511)
Commits
-------
bda4129 Make run() fully non-blocking and fix potential other problems
Discussion
----------
Make run() fully non-blocking and fix potential other problems
Multiple changes:
1) make writing to process non-blocking too - otherwise there might be increased possibility for buffer deadlock
given big enough input data. Also now it's guaranteed that all stdin data will be written.
2) get rid of fgets() - fgets() isn't really good function to use in case of non-blocking sockets. Data loss possible.
Commits
-------
7af003b [HttpFoundation] Allow stringable objects and numbers in response body + added tests
8126fb7 [HttpFoundation] Ensure response body is string, fixes#1378
Discussion
----------
[HttpFoundation] Ensure response body is string, fixes#1378
The issue in #1378 is clearly just a misuse of the class due but the error it triggers is confusing. This hopes to fix that.
---------------------------------------------------------------------------
by Seldaek at 2011/06/21 04:08:40 -0700
Added tests and support for __toString + numbers (kinda pointless but well..)
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
-------
1cb5164 Replace some double quotes to single quotes
12259d1 Replace optionNal to optional
Discussion
----------
Fixed typo and double quotes within some strings
Fixed typo and double quotes within some strings
Commits
-------
159fc0e [Validator] Added symbols to IDNs validation
c827faf [Validator] Add support for IDNs and custom TLDs
Discussion
----------
[Validator] Add support for IDNs and custom TLDs
Minor changes to allow for IDNs and [custom TLDs](http://news.softpedia.com/news/ICANN-Approves-New-Custom-Generic-Top-Level-Domains-Like-google-bank-206977.shtml). This is the only sane way to support everything in a timeless manner.
---------------------------------------------------------------------------
by stealth35 at 2011/06/20 04:32:09 -0700
maybe it should be check the host with idn_to_ascii (if function exists, maybe it's should recreate un punycode en/decoder in the stub)
---------------------------------------------------------------------------
by mvrhov at 2011/06/20 04:40:10 -0700
/me :faceslap.
Haven't seen the link in PR
---------------------------------------------------------------------------
by Seldaek at 2011/06/20 04:40:40 -0700
@mvrhov: Yup, that's what pushed me to reconsider adding this.
@stealth35: I'm not sure if this is needed. I don't want this to be too strict, with another validator or with an extra option I think we can make a check that the domain actually exists, or do a GET / on it or something, but this just checks validity of the syntax.
---------------------------------------------------------------------------
by stealth35 at 2011/06/20 04:48:05 -0700
I understand :)
what about funny IDN like : [☎.com] (http://xn--y3h.com/) ?
---------------------------------------------------------------------------
by Seldaek at 2011/06/20 04:53:19 -0700
@stealth35: Fixed
---------------------------------------------------------------------------
by stealth35 at 2011/06/20 04:56:18 -0700
it's seem great,for acceptable chars [RFC] (http://www.faqs.org/rfcs/rfc3490.html) said (with UseSTD3ASCIIRules option) :
(a) Verify the absence of non-LDH ASCII code points; that is, the
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
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
-------
f400124 [HttpFoundation] Small optimization of Session flash handling
Discussion
----------
[HttpFoundation] Small optimization of Session flash handling
Due to copy-on-write, this is faster and takes less memory unless the flashes are changed during the request, but that's not very likely as typically you set flashes, redirect, then show them, and at that point you do not modify them again.
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
-------
98b6f9b Fixed tests
ad1b690 [DoctrineBundle] Updated the XSD schema
41347bc [DoctrineBundle] Added the support of custom types for the platform
Discussion
----------
Doctrine mapping types
This adds the full support of Doctrine mapping type, allowing to use them in the SchemaTool. It closes#1349
---------------------------------------------------------------------------
by stof at 2011/06/17 02:05:45 -0700
See also symfony/symfony-docs#414 for the doc
---------------------------------------------------------------------------
by fabpot at 2011/06/17 02:18:03 -0700
Tests do not pass.
---------------------------------------------------------------------------
by stof at 2011/06/17 02:25:25 -0700
Fixed
---------------------------------------------------------------------------
by beberlei at 2011/06/17 03:27:58 -0700
+1
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
-------
72c074a [Session] Used \Locale::setDefault() when the locale is setted
Discussion
----------
[Session] Used \Locale::setDefault() when the locale is setted
For `DateType` in form component (by example), `\Locale::getDefault()` is used to displayed the name of months.
If `\Locale` class is not used when the locale is setted in the session, the name of months is not in a good language.
This PR solves this problem.
---------------------------------------------------------------------------
by pborreli at 2011/05/29 09:13:44 -0700
what if user doesn't have intl extension ?
---------------------------------------------------------------------------
by stof at 2011/05/29 09:24:04 -0700
You should wrap the calls to ``\Locale::setDefault`` in a ``class_exist`` check to avoid issue when using the stub implementation (for which calling ``setDefault`` is forbidden).
---------------------------------------------------------------------------
by francisbesset at 2011/05/29 09:26:40 -0700
@pborreli: Symfony have a fake Locale class and this class is used only if the server haven't intl enabled.
---------------------------------------------------------------------------
by stof at 2011/05/29 09:33:16 -0700
@francisbesset Yeah, but ``setDefault`` throw a ``BadMethodCall`` exception.
and so the check has to use ``extension_loaded`` instead of ``class_exists``.
---------------------------------------------------------------------------
by fabpot at 2011/06/13 10:12:15 -0700
Ticket #1121 is related to this PR.
---------------------------------------------------------------------------
by fabpot at 2011/06/15 06:18:28 -0700
I have just tried another implementation where the locale is passed as an argument to the built-in types and some data transformers (via a `LocaleAwareInterface` interface). That works fine as forms are immutable now, but the solution is obviously more "complex" as we need to pass the locale to many different classes. Also, using `Locale::setDefault()` has an advantage over my method: you can change the locale whenever you want within a PHP process (which can be useful even if this is an edge case). Last, but not the least, if make sense to update the PHP Locale to the user locale.
So, to sum up, this patch is probably the best solution (easy and flexible enough).
Commits
-------
e8326aa Renamed attributes to attr to be consistent with templating.
c707467 Added support for additional attributes in Form types that list field as their parent.
Discussion
----------
[Form] Added support for additional attributes
Added support for additional attributes in Form types that list field as their parent.
This is needed particularity for html5 data and data- attributes support, unfortunately $options['data'] is already taken, so adding a general $options['attributes'] is the easiest solution without breaking BC.
Now I know that this will be tempting for some to stuck style and class attributes here also, but I'd rather not restrict the keys that are passed in.
---------------------------------------------------------------------------
by Seldaek at 2011/05/22 14:51:02 -0700
Maybe it should be called attr for consistency with the template stuff, or the other should be renamed attributes. Other than that, I'm +1, data-* attributes are awesome, and abusers will find ways to abuse things either way.
---------------------------------------------------------------------------
by mvrhov at 2011/05/22 21:48:01 -0700
Naming it attr also crossed my mind when I was signing off yesterday.
Along with the possibility to go the way xml attributes are handled when node is converted to/from array.
So every option with @ prefix would automatically become html attribute. However going the latter path, it'd be harder to implement.
---------------------------------------------------------------------------
by fabpot at 2011/06/13 07:43:52 -0700
Can you give an example of a real-world use case? Thanks.
---------------------------------------------------------------------------
by Seldaek at 2011/06/13 07:54:51 -0700
You can use `array('attr' => array('data-foo' => 'bar'))`, which will output `data-foo="bar"`, which can be read easily by jQuery for example as `$('el').data('foo')`. It's a standard compliant and elegant way to pass extra data needed by the JS code along with DOM nodes, without polluting everything with script tags and all.
---------------------------------------------------------------------------
by fabpot at 2011/06/13 08:01:08 -0700
@Seldaek: I understand that. But why not doing this in the template?
---------------------------------------------------------------------------
by Seldaek at 2011/06/13 08:04:10 -0700
Well, I agree it most likely belongs in the template, but it's kind of data stuff that is not directly impacting the display rules of the element, so in some cases having the possibility to set that from the php code might be useful. Anyway I'll let @mvrhov answer maybe he had a more concrete use case. I just think it's nice to leave the door open, but I don't really need it.
---------------------------------------------------------------------------
by mvrhov at 2011/06/13 10:27:03 -0700
A bit late to the party. Ok, here is my use-case.
I have a pretty large form where part of the data is of tabular form. The number of rows is almost every time a lot larger than the number of columns
So I can either output a lot of text inputs filled with data and make already a large form intimidating. Or I can use a grid that supports editing. So I serialize that tabular data as json and put it as a value into one hidden field. Somehow I also have to get the column definitions to that grid. I decided to I serialize it and put it inside data-* attribute. Putting it into another hidden field doesn't make sense as when data is submitted back I don't need the column definitions as only the number of rows changes.
---------------------------------------------------------------------------
by fabpot at 2011/06/13 10:44:58 -0700
@mvrhov: ok, but what prevents you from doing this in the template directly?
---------------------------------------------------------------------------
by mvrhov at 2011/06/13 11:22:53 -0700
I have to get it into the view somehow. What I'd really not like to do is, iterate through that data in a controller and then pass it as another template variable.
---------------------------------------------------------------------------
by fabpot at 2011/06/14 00:10:22 -0700
But the controller is where you prepare the data that you want to send to the view. Without any concrete example, I'm going to close this PR.
---------------------------------------------------------------------------
by mvrhov at 2011/06/14 01:21:10 -0700
IMHO this has to go out through form as this is the part of the form also I do have a very slim controllers in this case 10 LOC, where half of them is just setting up an view data..
Nonetheless I went looking again very closely at the AbstractType and I do have buildView function available which I can override and set the column data I need there, and then provide custom view for that, so at least from this part this is an non issue.
With this PR all default form attributes can be set from outside and when searching for a good use-case I have found out that @henrikbjorn has implemented this via extensions [1], maybe he has a good use-case for this.
[1] - https://github.com/Comways/ComwaysFormExtraBundle/blob/master/Form/Extension/FieldTypeExtension.php
---------------------------------------------------------------------------
by henrikbjorn at 2011/06/14 01:48:53 -0700
Convenience is the only use case
---------------------------------------------------------------------------
by stof at 2011/06/14 02:08:09 -0700
@fabpot The issue is that passing it from the controller as another template variable makes it really hard when you use the type twice with different values. Passing them from the form would be the easiest way
---------------------------------------------------------------------------
by shuogawa at 2011/06/14 19:37:50 -0700
hello. thanks for great form library.
I want to support two ways to display additional attributes for form elements.
1) control in template like
{{ form_row(form.name, { 'width': '30' }) }}
2) control from php
$builder->add('name', 'text', array('attr'=>array('width'=>'30')));
If form elements configure by end user like cms,
and form elements dynamically change.
The second method is useful.
template designer can write {{form_row(form)}}
but
template designer can not write {{form_row(form.name), { 'width': '30' }}}
Thank you
---------------------------------------------------------------------------
by fabpot at 2011/06/14 23:01:18 -0700
@shuogawa: That's what I fear. Setting the `width` or any other attribute in PHP is wrong. This belongs to the templates.
---------------------------------------------------------------------------
by stloyd at 2011/06/15 00:09:05 -0700
@fabpot Then maybe just restrict allowed tags to `data-*` and don't use `attr` but some other not confusing name ? Just like we do with i.e. `maxlength`.
---------------------------------------------------------------------------
by fabpot at 2011/06/15 04:44:25 -0700
I'm going to merge it as a "convenience" tool, but the documentation should clearly state that the only usage should be for `data-*` attributes.
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 !
Commits
-------
49dd558 Couple more CS fixes
5a986bf Add $keysCount & minor CS fix
91f4097 [Routing] Better nesting for RouteCollections in dumped URL matcher classes With this change, a route prefixed with '/blogger' will be nested inside '/blog' (for example)
Discussion
----------
[Routing] Better nesting for RouteCollections in dumped URL matcher classes
Consider the following routing file:
_blog:
resource: "@AcmeDemoBundle/Resources/config/routing/BlogController.yml"
prefix: /blog
_blogger:
resource: "@AcmeDemoBundle/Resources/config/routing/BloggerController.yml"
prefix: /blogger
_bloggeroo:
resource: "@AcmeDemoBundle/Resources/config/routing/BloggerooController.yml"
prefix: /bloggeroo
_blogtest:
pattern: /blogtest
defaults: { _controller: AcmeDemoBundle:Blog:test }
login:
pattern: /login
defaults: { _controller: AcmeDemoBundle:Security:login }
Note: Each imported file contains two simple blog/blogger/bloggeroo routes (e.g. blog_index & blog_view)
With this change, the cached URL matcher looks something like this:
```php
<?php
class appprodUrlMatcher
{
public function match($pathinfo)
{
$allow = array();
if (0 === strpos($pathinfo, '/blog')) {
// blog_index
if (preg_match('#^/blog/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {...}
// blog_view
if (preg_match('#^/blog/(?P<year>\d{4})/(?P<month>\d{2})/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {...}
if (0 === strpos($pathinfo, '/blogger')) {
// blogger_index
if (preg_match('#^/blogger/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {...}
// blogger_view
if (preg_match('#^/blogger/(?P<year>\d{4})/(?P<month>\d{2})/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {...}
if (0 === strpos($pathinfo, '/bloggeroo')) {
// bloggeroo_index
if (preg_match('#^/bloggeroo/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {...}
// bloggeroo_view
if (preg_match('#^/bloggeroo/(?P<year>\d{4})/(?P<month>\d{2})/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {...}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
// _blogtest
if ($pathinfo === '/blogtest') {...}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
// login
if ($pathinfo === '/login') {...}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
}
```
As far as I can see, you can throw the 404 earlier (as I've done), as by nesting all these possibilities, there is no chance another route will be matched outside the parent if statement.
---------------------------------------------------------------------------
by stloyd at 2011/06/11 08:37:15 -0700
You should follow Symfony [CS rules] (http://symfony.com/doc/current/contributing/code/standards.html), also you should modify tests.
---------------------------------------------------------------------------
by lmcd at 2011/06/11 08:46:32 -0700
Besides the inline `continue` statement, I can't see spot any other CS violations. I'm on to the updated tests.
---------------------------------------------------------------------------
by fabpot at 2011/06/13 02:19:14 -0700
What if you have this:
_blog:
resource: "@AcmeDemoBundle/Resources/config/routing/BlogController.yml"
prefix: /blog
login:
pattern: /login
defaults: { _controller: AcmeDemoBundle:Security:login }
_blogger:
resource: "@AcmeDemoBundle/Resources/config/routing/BloggerController.yml"
prefix: /blogger
You cannot send 404 early because the same `blog` prefix is used in two different places. I can see many things that will break with this patch. I'm pretty sure we can enhance the performance of the existing code but let's do that after 2.0.
---------------------------------------------------------------------------
by lmcd at 2011/06/13 05:04:03 -0700
@fabpot: The code was designed so it would work in these kind of circumstances. I ran the dumper against the routing file you provided and this is the output below.
I see no reason why you can't throw the 404 earlier, as by nesting everything with similar prefixes, we're eliminating the possibility that a route will ever be matched outside of that if statement.
```php
public function match($pathinfo)
{
$allow = array();
if (0 === strpos($pathinfo, '/blog')) {
// blog_index
if (preg_match('#^/blog/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {
...
}
// blog_view
if (preg_match('#^/blog/(?P<year>\d{4})/(?P<month>\d{2})/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {
...
}
if (0 === strpos($pathinfo, '/blogger')) {
// blog_index
if (preg_match('#^/blogger/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {
...
}
// blog_view
if (preg_match('#^/blogger/(?P<year>\d{4})/(?P<month>\d{2})/(?P<slug>[^/]+?)$#x', $pathinfo, $matches)) {
...
}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
// login
if ($pathinfo === '/login') {
...
}
throw 0 < count($allow) ? new MethodNotAllowedException(array_unique($allow)) : new ResourceNotFoundException();
}
```
---------------------------------------------------------------------------
by fabpot at 2011/06/13 07:48:49 -0700
Can you add some more tests to ensure that everything works fine and that we won't have regressions later on? Thanks.
Commits
-------
e718474 fixed CS and unsude variable (PR #1319)
b552354 Executable Finder will now try to match if a file is already in the open_basedir list before searching it thru that list
Discussion
----------
open_basedir exhancements for Executable Finder
I've made the some changed to the Executable Finder in order to handle the open_basedir ability to specify files in the list not just directories.
This should fixsymfony/symfony#1319
Hope I didn't made any CS violations.
Commits
-------
9d6357c [HttpFoundation] Document the changes to the File classes
136b80a [HttFoundation] Add File::getExtension() as \SplFileInfo::getExtension() was introduced in PHP 5.3.6
38b3b74 [HttpKernel] Fix and test previous commit
ac0c00c [HttpFoundation] Make File extends \SplFileInfo
Discussion
----------
[HttpFoundation] Make File extends \SplFileInfo
This is a rebased version of [PR 674](https://github.com/symfony/symfony/pull/674).
* File: The API has changed (now extends \SplFileInfo),
* File: move() creates the target directory when it does not exist
* UploadedFile: introduction of getClientXXX() methods (for Size, OriginalName, MimeType)
If this PR does not get merged UploadedFile should at least be fixed: [Client.php](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Client.php#L124) relies on a last parameter which is no more defined and which is used to bypass [move_uploaded_file()](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/File/UploadedFile.php#L155) in test mode.
If this could be merged, I'll detail the changes in UPDATE.md
---------------------------------------------------------------------------
by fabpot at 2011/06/14 08:20:59 -0700
I'll merge it. Can you update the UPDATE file?
---------------------------------------------------------------------------
by vicb at 2011/06/14 09:24:01 -0700
done
Commits
-------
4016dfb [AsseticBundle] moved ExecutableFinder back into a closure so it's only called if needed
Discussion
----------
[AsseticBundle] moved ExecutableFinder back into a closure
[AsseticBundle] moved ExecutableFinder back into a closure so it's only called if needed
---------------------------------------------------------------------------
by fabpot at 2011/06/14 05:46:14 -0700
Does it relate to #1319?
---------------------------------------------------------------------------
by kriswallsmith at 2011/06/14 05:47:25 -0700
It's related, yes, but I don't think it's a solution for the issue.
---------------------------------------------------------------------------
by dlsniper at 2011/06/14 06:00:55 -0700
The issue in #1319 has been fixed with this: 0d54f5c21e
It's in the latest master tree but finding that file only when needed is also a good idea.
