Commits
-------
91cfb24 Made namespace for Doctrine cache unique to each environment
Discussion
----------
Made the cache namespace for the Doctrine cache extension unique to each environment
The current cache namespace for the Doctrine adapters is unique on an entity manager and the kernel root directory; however, it causes problems as settings for entity managers can differ between environments, so the addition of the environment into the namespace would address the issue.
$namespace = 'sf2orm_'.$entityManager['name'].'_'.md5($container->getParameter('kernel.root_dir'));
Solves issues with the cache not being valid for the DBAL ACL provider using D2 as the cache and switching environments.
An exception has been thrown during the rendering of a template ("Warning: Illegal offset type in isset or empty in ../vendor/symfony/src/Symfony/Component/Security/Acl/Dbal/AclProvider.php line 404")
Commits
-------
df34e0e [FrameworkBundle] Fix for setting a custom file link format (fixes#1652)
Discussion
----------
[FrameworkBundle] Fix for setting a custom file link format (fixes#1652)
[FrameworkBundle] Fix for setting a custom file link format (fixes#1652)
Solves issues with the cache not being valid for the DBAL ACL provider using D2 as the cache and switching environments.
An exception has been thrown during the rendering of a template ("Warning: Illegal offset type in isset or empty in ../vendor/symfony/src/Symfony/Component/Security/Acl/Dbal/AclProvider.php line 404")
Commits
-------
b96e0d3 Updated some awkward swedish validator message translations.
Discussion
----------
Updated some awkward swedish validator message translations.
Just a little more proper swedish.
Commits
-------
2a24603 [Routing] Allow multiple `@Route` annotations with a default name on a single method (fixes#1647)
Discussion
----------
[Routing] Allow multiple `@Route` annotations with a default name
[Routing] Allow multiple `@Route` annotations with a default name on a single method (fixes#1647)
Before this change, the default name would be the same for multiple `@Route` with a default name on the same method. Then only the last declared route is active.
The defaults names are (for consecutive `@Route`s):
* former_default,
* former_default_1,
* former_name,
* former_default_2,
* ...
The FrameworkExtraBundle needs to be updated in sync with this PR: https://github.com/sensio/SensioFrameworkExtraBundle/pull/50
Commits
-------
b2ce732 added chinese translations for validator messages
Discussion
----------
added chinese translations for validator messages
added chinese (simplified) translations for validator messages
Commits
-------
95ca258 Fixed problems with running processes returns wrong exitcode (-1) on Linux.
Discussion
----------
#1636
Fixed problems with running processes returns wrong exitcode (-1) on Linux.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/11 11:07:42 -0700
This doesn't concern this PR specifically, but can we somehow start adding tests for this class? The process component seems like the by far most unstable code that we have.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 23:07:43 -0700
@schmittjoh: Problem is that the behavior highly depends on the platform and PHP version.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 23:14:23 -0700
@schmittjoh: By the way, we have added a bunch of tests recently (2d29a82412 (tests)/Symfony/Tests/Component/Process). Things are also "unstable" because the behavior depends on the amount of input, the amount of output, and when things happens. That means that it is also impossible to cover all possible cases reliably.
Commits
-------
d34caee merged and unified blocks `field_label` and `form_label` into `generic_label`
Discussion
----------
merged and unified blocks `field_label` and `form_label` into `generic_label`
Commits
-------
4764cfb [FrameworkBundle] Added Swedish translation
Discussion
----------
Added Swedish translations
Here's a Swedish translation for the validation error messages.
Commits
-------
11369eb Fixed phpdoc
dbe1854 Added a AccessDeniedHttpException to wrap the AccessDeniedException.
Discussion
----------
Added a AccessDeniedHttpException to wrap the AccessDeniedException.
This is a proposal to fix#1631
It wraps the AccessDeniedException in an AccessDeniedHttpException when the firewall is not able to handle it itself. This allows getting a 403 response using the standard exception listener in this case.
Note that the app should not throw the AccessDeniedHttpException itself but keep using the AccessDeniedException to let the Security component check if the user is already fully authenticated or if it should give a chance to authenticate.
---------------------------------------------------------------------------
by fabpot at 2011/07/11 07:10:12 -0700
For reference, I've tried something more radical some time ago here: https://github.com/symfony/symfony/pull/369.
---------------------------------------------------------------------------
by stof at 2011/07/11 07:22:07 -0700
my implementation is what @schmittjoh suggested in the comments on your PR.
Commits
-------
52fdd53 [Bridge/Twig] Add required class to labels that match required fields
Discussion
----------
[Bridge/Twig] Add required class to labels that match required fields
I have used this to simply style labels that are required with a red star behind them using this CSS:
``` css
label.required::after {
content: " *";
color: #c00;
}
```
The problem is that you can't use `input[required] + label::after` as a selector since the label is typically rendered before the input. There is no way to check for an element that is *followed by* another, only elements *following*.
Of course this CSS in particular won't work except in the latest browsers, but you could still use the `label.required` selector to add a background image and so on. I think this is a very common use case and therefore I think it'd benefit the core framework.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 01:27:49 -0700
Can you also update the PHP templates?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 01:43:33 -0700
How about namespacing these css classes, like for example "sf-form-required"?
---------------------------------------------------------------------------
by stloyd at 2011/07/05 01:50:58 -0700
I would prefer an @schmittjoh naming, or even adding ability to setup it thought options.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 01:54:36 -0700
Please, do not add more options. Prefix with `sf` is actually a good idea but people will argue that this is not a good idea because it gives too much information about the technology used to create the website (that's one of the things that came up pretty often in symfony1).
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:00:11 -0700
An option is not such a good idea imo since you likely want to have a uniform naming strategy across your entire site. How about adding a new service CssNamingStrategy?
---------------------------------------------------------------------------
by stloyd at 2011/07/05 02:01:19 -0700
Then this can be some simpler one not giving such informations i.e.: `form-label-required`, `label-required`, `framework-form-required`, `form-required` or whatever else ;-)
---------------------------------------------------------------------------
by fabpot at 2011/07/05 02:16:41 -0700
It cannot be configurable as it would potentially break bundles that come with stylesheets.
---------------------------------------------------------------------------
by stloyd at 2011/07/05 02:21:10 -0700
IMO if we decide to add this one, we could add same to `inputs/selects/etc` with `required` option.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:21:59 -0700
I think it can, consider an interface like this:
```php
interface CssNamingStrategyInterface
{
function getCssName($class);
}
```
This will give people a lot of flexibility, and it also does allow them to exclude classes which for example are provided by third-party bundles.
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 02:47:54 -0700
Wow guys, if this turns into a full blown class generator solution, I'm happy to close the PR.
"required" is not a name that's commonly used for main page elements, it's typically associated with forms, and therefore I don't see the need to make it unnecessary longer/namespaced. Similarly I don't see the need to add it to the input/select/.., because they already have an attribute, which you can very easily select as: `input[required]` in CSS. That works everywhere except IE6, but we can't build for the future on very old browsers. If you really want support for IE6, you can override the templates imo. But core should be looking forward, as it already is with HTML5, form markup, etc.
As for calling it form-label-required or label-required, again, I don't see the benefit, you can use `label.required` if you want to avoid conflicts with non-label elements having a required class, or a safer `form .required`. There are plenty of options in CSS itself, let's not make this overly complex.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:52:17 -0700
see
http://code.google.com/intl/de-DE/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
On Tue, Jul 5, 2011 at 11:47 AM, Seldaek <
reply@reply.github.com>wrote:
> Wow guys, if this turns into a full blown class generator solution, I'm
> happy to close the PR.
>
> "required" is not a name that's commonly used for main page elements, it's
> typically associated with forms, and therefore I don't see the need to make
> it unnecessary longer/namespaced. Similarly I don't see the need to add it
> to the input/select/.., because they already have an attribute, which you
> can very easily select as: `input[required]` in CSS. That works everywhere
> except IE6, but we can't build for the future on very old browsers. If you
> really want support for IE6, you can override the templates imo. But core
> should be looking forward, as it already is with HTML5, form markup, etc.
>
> As for calling it form-label-required or label-required, again, I don't see
> the benefit, you can use `label.required` if you want to avoid conflicts
> with non-label elements having a required class, or a safer `form
> .required`. There are plenty of options in CSS itself, let's not make this
> overly complex.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1519#issuecomment-1502560
>
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 03:11:50 -0700
Really? Come on, we're talking about forms, it's not like you have billions of form/input tags per page that have to be parsed by the browser when you select that. Also you don't have to select the elements, if you want true performance just use no stylesheet, your users will thank you.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 03:30:40 -0700
Your CSS selectors not only affect the performance of form elements, but of all elements that have a "required" class. Likewise, the same applies if we decide to add more classes.
Why close the door for people who care about performance? We can easily avoid this by making the css class more specific as suggested earlier. The idea with the renaming strategy is one step further and allows people to "obfuscate" which tool was used to generate the form, or do additional optimizations like shortening the css name.
---------------------------------------------------------------------------
by lenar at 2011/07/05 03:34:34 -0700
@Seldaek: Just for remark I've seen matrix forms spanning multiple screenfuls horizontally and vertically
containing tens of thousands inputs. Not pretty, but they do exist. Basically "poor" man's/company's excel
emulation or something.
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 04:19:13 -0700
@schmittjoh, @lenar: We're catering to the most common use case, for which this will be more than fast enough. Small/medium scale websites don't have to optimize on CSS rules parsing, they usually have much bigger issues to deal with. If you really care about it, overriding the block to remove the class is just as easy as it was to for me to add it, but IMO this is the edge case.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 05:37:19 -0700
IMO Symfony should follow best practices by encouraging to use class selectors, and not tag selectors for the reasons explained on the page I linked.
Anyway, I think everybody made his points. Time for @fabpot to make a decision :)
