Commits
-------
218813c [Finder] contains(), notContains()
33e119a Merge branch 'master' of https://github.com/symfony/symfony into finder_search_by_contents
082d86e [Finder] content(), notContent() methods
Discussion
----------
[Finder] search by contents
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Sometimes I need to search for files containing some text:
```
$finder
->content('lorem')->notContent('ipsum')
->content('/^Begining/m')->notContent('/the end$/m');
```
I don't know how to tests exceptions thrown by `file_get_contents()` calls.
---------------------------------------------------------------------------
by gajdaw at 2012-04-19T15:53:05Z
To keep it as close as possible to `name` and `notName`.
Commits
-------
94bee7a [Filesystem] symlink() creates target directories
Discussion
----------
[Filesystem] symlink() creates target directories
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes [](http://travis-ci.org/michal-pipa/symfony)
Fixes the following tickets: #3967
Todo: -
Changed symlink() method behavior to recursively create target directory if it does not exist. It makes Filesystem component methods more consistent since copy() does the same. It is also more convenient.
Also mirror() fails to create symlink in non-existent directory (if we don't want to change symlink(), than we need to fix mirror()).
Fixes: #3967
Commits
-------
1c290d7 Add unit tests for FlattenException::getLine() and FlattenException::getFile().
a22f0cd Enhance FlattenException to include more methods from Exception. That allows it to be used in place of Exception in more places.
Discussion
----------
[HttpKernel] Enhance FlattenException to include more methods from Exception.
I'm trying to retrofit FlattenException into Drupal, in places where Drupal expects an Exception. That doesn't quite work though, as FlattenException only has some of the methods from Exception. I'm not entirely clear why it only has some, but this PR adds getFile() and getLine() so that it's a more ready drop-in. I did not add them to the toArray() method for fear of breaking BC somewhere, but that could be done as well no doubt if folks felt it was appropriate.
Note: While the parts of Drupal in question will get rewritten later anyway, I think having this information exposed is a good thing in general for logging purposes if nothing else. It's already possible to dig it out of the trace, so this is just an improved "Developer eXperience" (DX).
---------------------------------------------------------------------------
by fabpot at 2012-04-20T04:34:54Z
I'm +1 to make `FlattenException` more "compatible" with `Exception`. Can you add the other missing methods? Also, you need to populate the `$this->file` and `$this->line` value in the constructor.
---------------------------------------------------------------------------
by Crell at 2012-04-20T04:48:40Z
I knew I was forgetting something obvious...
According to http://us.php.net/manual/en/class.exception.php, I think the only other missing method is http://us.php.net/manual/en/exception.gettraceasstring.php. I'm not sure how useful that is, but I can try to approximate it if you think it's necessary. (Honestly I've never used that method on an exception myself.)
I should probably add some tests, too. Stand by for those.
---------------------------------------------------------------------------
by Crell at 2012-04-20T05:00:28Z
Now includes unit tests to make sure I didn't do anything stupid this time. I'll hold off on getTraceAsString() for now unless you think it's needed. (I'm not sure it is since it's harder to do and IMO less useful.)
Commits
-------
748bbe1 Make windows test run on windows only
e7f1295 [Filesystem] Fix Filesystem::chmod to apply umask properly
5c059aa Fix chmod() calls to apply umask
13c07d1 [Filesystem] Fix typo
c578d3a [Filesystem] Fix makePathRelative on windows with mixed paths, fix tests
Discussion
----------
[Filesystem][Others] Fix chmod method and all calls to chmod throughout the framework
Fixes the issue I mentioned in #4004 - basically php's chmod() does not apply the umask by default (unlike mkdir's mode arg which is masked by umask, from which I guess the confusion comes from).
So I expanded all cache writes and such to 0666 when they were 0644, and then mask it against umask, so that we respect the user settings a bit better.
Also fixed Filesystem::chmod which completely ignored the umask argument before.
Fixed a few tests on windows too.
Commits
-------
8bdff01 [DoctrineBridge][Form] added collection guess for array Doctrine type and array constraint type
Discussion
----------
[Form] [DoctrineBridge] Better field type guessing for array doctrine type and array validator type
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1692
Todo: -
---------------------------------------------------------------------------
by bschussek at 2012-04-18T08:45:17Z
Could you please add an entry to the CHANGELOG and squash your commits into one?
---------------------------------------------------------------------------
by pvanliefland at 2012-04-18T17:20:39Z
Done
Commits
-------
725423c Add test to prevent regressions
3b2f542 Fix asset generation with an empty asset
Discussion
----------
[Templating] Return base URL when an empty path is given to asset()
I think it's straightforward enough in the patch. Tests pass. It's quite useful to generate the base path to send to a JS frontend.
Commits
-------
b7b26af [DependencyInjection] Added, implemented and tested IntrospectableContainerInterface::initialized()
Discussion
----------
[DependencyInjection] IntrospectableContainerInterface::initialized()
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Added, implemented and tested `IntrospectableContainerInterface::initialized()`, which allows checking for whether or not a service id has actually been loaded, without forcing it to load. This could be implemented in several places to prevent loading a service when it's only needed if it has been previously loaded - for example the SwiftmailBundle's event listener for the `kernel.terminate` event, which currently forces Swiftmail to load on every request to check for messages to send, even if it was not previously loaded.
---------------------------------------------------------------------------
by fabpot at 2012-03-11T09:10:32Z
Do you have any other examples in mind where it would be useful?
---------------------------------------------------------------------------
by stof at 2012-03-11T12:39:22Z
@fabpot 2 exemples:
- the Swiftmailer listener to avoid loading the initialization code of Swiftmailer in each kernel.terminate event just to check that there is no pending message in the spool (if the spool has never been retrieved, it cannot have messages) (this is the use case we discussed on IRC last night)
- closing Doctrine connections and Monolog handlers in the shutdown method without creating them if they were not used
---------------------------------------------------------------------------
by stof at 2012-03-11T12:39:53Z
However, I don't like the name of the method
---------------------------------------------------------------------------
by lsmith77 at 2012-03-11T13:26:34Z
sounds very useful
---------------------------------------------------------------------------
by evillemez at 2012-03-11T17:00:39Z
@fabpot another example:
* Forcing a session to write early, if it was previously loaded - but not having to load the session to check, thus potentially forcing a database connection (if that's how the session is being handled) when it's not needed.
@stof Would more or less verbose be better? Like, `isServiceLoaded()` or just `loaded()`.... or a better word than "loaded" ? :)
---------------------------------------------------------------------------
by stof at 2012-03-11T17:03:11Z
@evillemez My issue is the word ``loaded``. I don't think it is clear about what it means here
---------------------------------------------------------------------------
by lsmith77 at 2012-03-11T17:04:24Z
one thing we should also keep in mind here is the scope of the service.
BTW: there are also a couple of CS violations in your PR
---------------------------------------------------------------------------
by fabpot at 2012-03-11T17:07:43Z
@stof: I agree that we should think of a better name: `initialized()` or `exists()` (to differentiate from `has()`)?
@evillemez: After choosing the name, can you work on actually using the new method for some of the use cases mentioned in this PR?
---------------------------------------------------------------------------
by lsmith77 at 2012-03-11T17:20:12Z
what i meant with "scope" was if we are only talking about services instantiated in the current scope? but i guess there is no way to handle anything else anyway.
as for name .. i think ``instantiated()`` is more fitting than ``initialized()``.
``exists()`` could be confused with ``has()`` imho
---------------------------------------------------------------------------
by stof at 2012-03-11T17:26:06Z
The current implementation only works for container-scoped services. It does not make sense for prototyped-scope services anyway (as the container does not keep them) but supporting scoped services will be tricky IMO
---------------------------------------------------------------------------
by mvrhov at 2012-03-11T17:34:21Z
hasBeen(Used|Called|Initialized),
---------------------------------------------------------------------------
by evillemez at 2012-03-11T17:54:43Z
The next day or two I'm only around for an hour or so here and there, I may be a little slow to respond.
@stof @lsmith77 I agree with either `instantiated()` or `initialized()`, I also think `exists()` might be easily confused with `has()`
@lsmith77 Besides the opening/closing brace placements, was there anything else?
@fabpot I would happily implement it in the Swiftmail bundle - as of now that's the only area where I know absolutely it would be useful. The Session example I mentioned was an issue I ran into working on another app in another framework, and I'm not familiar yet with the internals of the Monolog/Doctrine Bundles. But if people could point me in the right direction I'd be willing to check it out.
I'm still relatively new to some of the Symfony2 internals, so if there are obvious things I'm missing, please don't hesitate to point them out. :)
---------------------------------------------------------------------------
by evillemez at 2012-03-11T18:00:29Z
@lsmith77 Oh... I think there were some tab issues I didn't see in my editor, I'll fix those too.
---------------------------------------------------------------------------
by stof at 2012-03-11T18:13:03Z
The places where it should be used for Doctrine and Monolog are in separate repos anyway so it cannot be part of this PR
---------------------------------------------------------------------------
by evillemez at 2012-03-12T03:38:50Z
Any thoughts on `instantiated` vs `initialized`? I'm leaning towards `initialized`.
How should I proceed, close this request and submit another with the changed name and fixed CS violations?
---------------------------------------------------------------------------
by fabpot at 2012-03-12T07:41:11Z
`initialized()` looks fine to me. Make your changes, squash your commits and then force the push to your branch (the PR will be updated automatically).
---------------------------------------------------------------------------
by evillemez at 2012-03-12T20:49:17Z
I was about to squash my commits to update this, but it just occurred to me that I hadn't considered the interface. Does anyone feel this method `initialized()` should be defined in ContainerInterface as well? It seems like it's generic enough that it would make sense. But I'm not immediately aware if this would cause BC breaks.
---------------------------------------------------------------------------
by fabpot at 2012-03-13T11:34:33Z
We cannot break BC for `ContainerInterface` as this is marked with the `@api` tag.
---------------------------------------------------------------------------
by henrikbjorn at 2012-03-13T12:34:42Z
Is it a BC break if we add a method? i thought only changing the already written methods would be a BC break.
---------------------------------------------------------------------------
by ooflorent at 2012-03-13T12:39:44Z
@henrikbjorn It will raise a fatal error if the method isn't implemented in existing class.
---------------------------------------------------------------------------
by lsmith77 at 2012-03-13T13:06:26Z
we could however add a new interface that extends from the previous one.
---------------------------------------------------------------------------
by evillemez at 2012-03-13T15:40:39Z
Are the BC breaks we are worried about for compatibility just within the Symfony repo - or in general in case others have implemented the interface elsewhere? As far as Symfony is concerned, the only class I can find that implements `ContainerInterface` is `Container`, so adding the method shouldn't be an issue.
If it's an issue of principle, in case others may have implemented the `ContainerInterface`, then... yeah, it's a break, and maybe should be left out. I suppose this would mean that other places in code that type hint for `ContainerInterface` would have to change the type hint to `Container` if they want to implement the `initialized()` method.
Is this more or less acceptable than updating the interface?
---------------------------------------------------------------------------
by evillemez at 2012-03-14T19:17:27Z
Hadn't properly squashed commits, just fixed.
---------------------------------------------------------------------------
by evillemez at 2012-03-15T14:06:38Z
I'm done with this PR, unless there is a consensus that I should also implement `Container::initialized()` in `ContainerInterface`.
Anything else I need to do?
---------------------------------------------------------------------------
by Seldaek at 2012-03-15T15:41:44Z
@evillemez the common pattern for BC is to add a new interface, say IntrospectableContainerInterface or something, that extends ContainerInterface, then you can type-hint that without restricting use of competing implementations of the Container class.
---------------------------------------------------------------------------
by stof at 2012-04-03T22:30:51Z
@evillemez Please update this PR. It conflicts with master because of the move of tests. And the new interface suggested by @Seldaek is a good idea IMO
---------------------------------------------------------------------------
by evillemez at 2012-04-04T14:57:29Z
@Stof I may not be able to get to this until the end of the week, but I'll do it as soon as I can.
I'll rebase against the current master, and add/implement the interface. Is `IntrospectableContainerInterface ` as suggested by @Seldaek ok with everyone?
Are there other features that we can think of that would be useful for this new interface? I don't want to start a precedent of adding a new interface for every new method that comes up... I understand it makes sense for not breaking backwards compatibility for something previously marked as stable, but still, it's yet another file that will likely be included on every request.
---------------------------------------------------------------------------
by stof at 2012-04-04T15:35:15Z
@evillemez classes used on every requests can be added to some cached bootstrap files (which are loaded during the ``$kernel->loadClassCache()`` call in your front controller) to avoid including many files through the autoloader. And for even better performances in prod, the solution is to use APC with ``apc.stat = 0``, as advocated by @lsmith77
---------------------------------------------------------------------------
by evillemez at 2012-04-15T19:00:07Z
Ok, rebased against current master and implemented the interface. I didn't mark it as `@api` because I think we may want to consider if there's any other functionality that could be implemented there before declaring it stable.
Sorry for the delay. My wife and I are in the process of buying a house, and some unexpected things have come up.
---------------------------------------------------------------------------
by fabpot at 2012-04-18T10:59:01Z
Can you rebase before I merge? Thanks.
Commits
-------
6e4ed9e [Form] Fixed regression: bind(null) was not converted to an empty string anymore
fcb2227 [Form] Deprecated FieldType, which has been merged into FormType
bfa7ef2 [Form] Removed obsolete exceptions
2a49449 [Form] Simplified CSRF mechanism and removed "csrf" type
Discussion
----------
[Form] Merged FieldType into FormType
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3878
Todo: update the documentation on theming
This PR is a preparatory PR for #3879. See also #3878.
---------------------------------------------------------------------------
by juliendidier at 2012-04-13T14:25:19Z
What's the benefit ?
---------------------------------------------------------------------------
by henrikbjorn at 2012-04-13T14:26:40Z
why `input_widget` ? and not just `widget`
---------------------------------------------------------------------------
by Burgov at 2012-04-13T14:27:49Z
@juliendidier dynamic inheritance is now obsolete which fixes some other issues
---------------------------------------------------------------------------
by stloyd at 2012-04-13T14:37:26Z
What about __not__ breaking API so *badly* and leaving `FieldType` which will be simple like (with marking as deprecated):
```php
<?php
class FieldType extends AbstractType
{
public function getParent(array $options)
{
return 'form';
}
public function getName()
{
return 'field';
}
}
---------------------------------------------------------------------------
by bschussek at 2012-04-13T14:43:41Z
@stloyd That's a very good idea.
---------------------------------------------------------------------------
by mvrhov at 2012-04-13T17:41:21Z
IMHO what @stloyd proposed sounds like a good idea, but removing FieldType class, if #3903 will come into life might ensure that more forms will broke and people will check them thoroughly.
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-04-13T18:46:08Z
@bschussek looks great, but I'm concerned about how quickly will the third-party bundles adapt to this BC break. I hope really quick, because if they don't the whole stuff will be useless :S of course it's not your problem to solve.
---------------------------------------------------------------------------
by stof at 2012-04-13T18:50:32Z
@r1pp3rj4ck there is already another BC break requiring to update custom types for Symfony master. So third party bundles already have to do some work.
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-04-13T18:59:37Z
@stof which one? I've looked into @bschussek 's RFC about these [foo].bar stuff, but it's not yet implemented. Are you refering to this or another one I've missed?
---------------------------------------------------------------------------
by stof at 2012-04-13T19:04:06Z
@r1pp3rj4ck the change regarding default options
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-04-13T19:06:10Z
@stof oh, I forgot that one. Weird thing is that I've already changed my default options today and still forgetting these stuff :D
---------------------------------------------------------------------------
by bschussek at 2012-04-14T08:58:29Z
I restored and deprecated FieldType now. I'd appreciate further reviews.
---------------------------------------------------------------------------
by stloyd at 2012-04-14T09:02:32Z
Maybe we should try to avoid this BC in templates ? What do you think about similar move like with `FieldType` ? (hold old, but inside just render new)
---------------------------------------------------------------------------
by bschussek at 2012-04-14T09:07:22Z
@stloyd You mean for those cases where people explicitely render the block "field_*"? We can do that.
---------------------------------------------------------------------------
by stloyd at 2012-04-14T09:09:45Z
@bschussek Yes I mean this case =) Sorry for not being explicit, I need some coffee I think =)
---------------------------------------------------------------------------
by bschussek at 2012-04-17T14:45:35Z
I added the field_* blocks again for BC. Could someone please review again? Otherwise this can be merged.
---------------------------------------------------------------------------
by Burgov at 2012-04-17T15:11:16Z
@bschussek I'm not sure what has changed to cause this, but if I try out your branch on our forms, if I leave the value of an input empty, eventually the reverseTransform method receives a null value, rather than a '' (empty string) value, as on the current symfony master.
DateTimeToLocalizedStringTransformer, for example, will throw an Exception if the value is not a string
```php
if (!is_string($value)) {
throw new UnexpectedTypeException($value, 'string');
}
```
Other than that, all forms render just the same as they do on symfony master
---------------------------------------------------------------------------
by bschussek at 2012-04-17T15:30:29Z
@Burgov Fixed.
Commits
-------
24bd8f4 Added missing dot to translation messages.
4bff221 Added missing dot to translation messages.
7454894 Added missing dot to translation messages.
6e90c50 Updated upgrade instructions.
7e21dd1 Added missing dot to translation messages.
Discussion
----------
Issue 3379
This should fix [issues 3379](https://github.com/symfony/symfony/issues/3379)
---------------------------------------------------------------------------
by stof at 2012-04-13T15:06:32Z
Your branch conflicts with master. Please rebase it
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:11:54Z
@stof I tried to rebase, I'm not sure if I did everything right. Is it ok now?
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:12:06Z
@stof I tried to rebase, I'm not sure if I did everything right. Is it ok now?
---------------------------------------------------------------------------
by mvrhov at 2012-04-13T19:19:34Z
IMHO no, because there are commits from other people. Did you follow the [instructions](http://symfony.com/doc/current/contributing/code/patches.html#id1)?
---------------------------------------------------------------------------
by stof at 2012-04-13T19:36:53Z
@mvrhov commits from others ?
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:41:53Z
@stof There were some, so I reverted. Now I'm trying again following instructions from Symfony doc.
I come to this:
```
$ git push origin issue-3379
To git@github.com:umpirsky/symfony.git
! [rejected] issue-3379 -> issue-3379 (non-fast-forward)
error: failed to push some refs to 'git@github.com:umpirsky/symfony.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
```
And I don't know how to fix this. Any idea?
---------------------------------------------------------------------------
by stof at 2012-04-13T19:43:45Z
@umpirsky when you rebase, it is logical to need to force the push
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:44:38Z
@stof I did `git push -f origin issue-3379`. I hope it's fixed now.
---------------------------------------------------------------------------
by maoueh at 2012-04-13T20:39:34Z
@umpirsky seems better than last time I checked :)
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T20:43:04Z
@maoueh Is it good enough? :)
---------------------------------------------------------------------------
by maoueh at 2012-04-13T20:51:27Z
@umpirsky At least, the rebase seems good enough :D As for the subject of the PR, I don't pronounce myself ;)
---------------------------------------------------------------------------
by vicb at 2012-04-13T20:53:23Z
you should probably squash the commits
