Skip to content

Commit

Permalink
Merge branch '2.8' into 3.0
Browse files Browse the repository at this point in the history
Conflicts:
	cookbook/security/_ircmaxwell_password-compat.rst.inc
	create_framework/introduction.rst
  • Loading branch information
xabbuh committed Dec 23, 2015
2 parents f625981 + cf2fb97 commit ae53c89
Show file tree
Hide file tree
Showing 25 changed files with 162 additions and 188 deletions.
8 changes: 4 additions & 4 deletions book/doctrine.rst
Expand Up @@ -953,8 +953,8 @@ To relate the ``Category`` and ``Product`` entities, start by creating a
products:
targetEntity: Product
mappedBy: category
# don't forget to init the collection in the __construct() method
# of the entity
# Don't forget to initialize the collection in
# the __construct() method of the entity
.. code-block:: xml
Expand Down Expand Up @@ -1096,7 +1096,7 @@ table, and ``product.category_id`` column, and new foreign key:
.. note::

This task should only be really used during development. For a more robust
This command should only be used during development. For a more robust
method of systematically updating your production database, read about
`migrations`_.

Expand Down Expand Up @@ -1187,7 +1187,7 @@ You can also query in the other direction::
// ...
}

In this case, the same things occurs: you first query out for a single ``Category``
In this case, the same things occur: you first query out for a single ``Category``
object, and then Doctrine makes a second query to retrieve the related ``Product``
objects, but only once/if you ask for them (i.e. when you call ``->getProducts()``).
The ``$products`` variable is an array of all ``Product`` objects that relate
Expand Down
17 changes: 11 additions & 6 deletions book/forms.rst
Expand Up @@ -223,8 +223,8 @@ Handling Form Submissions

The second job of a form is to translate user-submitted data back to the
properties of an object. To make this happen, the submitted data from the
user must be written into the form. Add the following functionality to your
controller::
user must be written into the Form object. Add the following functionality to
your controller::

// ...
use Symfony\Component\HttpFoundation\Request;
Expand Down Expand Up @@ -694,9 +694,14 @@ the documentation for each type.
The most common option is the ``required`` option, which can be applied to
any field. By default, the ``required`` option is set to ``true``, meaning
that HTML5-ready browsers will apply client-side validation if the field
is left blank. If you don't want this behavior, either set the ``required``
option on your field to ``false`` or
:ref:`disable HTML5 validation <book-forms-html5-validation-disable>`.
is left blank. If you don't want this behavior, either
:ref:`disable HTML5 validation <book-forms-html5-validation-disable>`
or set the ``required`` option on your field to ``false``::
->add('dueDate', 'date', array(
'widget' => 'single_text',
'required' => false
))

Also note that setting the ``required`` option to ``true`` will **not**
result in server-side validation to be applied. In other words, if a
Expand Down Expand Up @@ -935,7 +940,7 @@ specify it:

Some field types have additional rendering options that can be passed
to the widget. These options are documented with each type, but one common
options is ``attr``, which allows you to modify attributes on the form element.
option is ``attr``, which allows you to modify attributes on the form element.
The following would add the ``task_field`` class to the rendered input text
field:

Expand Down
6 changes: 3 additions & 3 deletions book/templating.rst
Expand Up @@ -201,7 +201,7 @@ First, build a base layout file:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta charset="UTF-8">
<title>{% block title %}Test Application{% endblock %}</title>
</head>
<body>
Expand All @@ -226,7 +226,7 @@ First, build a base layout file:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta charset="UTF-8">
<title><?php $view['slots']->output('title', 'Test Application') ?></title>
</head>
<body>
Expand Down Expand Up @@ -311,7 +311,7 @@ output might look like this:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta charset="UTF-8">
<title>My cool blog posts</title>
</head>
<body>
Expand Down
3 changes: 1 addition & 2 deletions contributing/code/patches.rst
Expand Up @@ -116,8 +116,7 @@ work:
* ``2.3``, if you are fixing a bug for an existing feature (you may have
to choose a higher branch if the feature you are fixing was introduced
in a later version);
* ``2.8``, if you are adding a new feature which is backward compatible;
* ``master``, if you are adding a new and backward incompatible feature.
* ``master``, if you are adding a new feature.

.. note::

Expand Down
4 changes: 2 additions & 2 deletions cookbook/assetic/asset_management.rst
Expand Up @@ -11,9 +11,9 @@ Starting from Symfony 2.8, Assetic is no longer included by default in the
Symfony Standard Edition. Before using any of its features, install the
AsseticBundle executing this console command in your project:

.. code-block:: bash
.. code-block:: bash
$ composer require symfony/assetic-bundle
$ composer require symfony/assetic-bundle
Then, enable the bundle in the ``AppKernel.php`` file of your Symfony application::

Expand Down
14 changes: 8 additions & 6 deletions cookbook/form/dynamic_form_modification.rst
Expand Up @@ -374,13 +374,15 @@ you need to register it as a service and tag it with :ref:`form.type <dic-tags-f
.. code-block:: php
// app/config/config.php
$definition = new Definition('AppBundle\Form\Type\FriendMessageFormType');
$definition->addTag('form.type');
$container->setDefinition(
'app.form.friend_message',
$definition,
array('security.token_storage')
use Symfony\Component\DependencyInjection\Reference;
$definition = new Definition(
'AppBundle\Form\Type\FriendMessageFormType',
array(new Reference('security.token_storage'))
);
$definition->addTag('form.type');
$container->setDefinition('app.form.friend_message', $definition);
In a controller that extends the :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\Controller`
class, you can simply call::
Expand Down
52 changes: 31 additions & 21 deletions cookbook/form/form_customization.rst
Expand Up @@ -264,7 +264,7 @@ directly in the template that's actually rendering the form.

.. code-block:: html+twig

{% extends '::base.html.twig' %}
{% extends 'base.html.twig' %}

{% form_theme form _self %}

Expand Down Expand Up @@ -303,7 +303,7 @@ can now re-use the form customization across many templates:

.. code-block:: html+twig

{# app/Resources/views/Form/fields.html.twig #}
{# app/Resources/views/form/fields.html.twig #}
{% block integer_widget %}
<div class="integer_widget">
{% set type = type|default('number') %}
Expand All @@ -319,7 +319,7 @@ tell Symfony to use the template via the ``form_theme`` tag:

.. code-block:: html+twig

{% form_theme form 'AppBundle:Form:fields.html.twig' %}
{% form_theme form 'form/fields.html.twig' %}

{{ form_widget(form.age) }}

Expand All @@ -335,13 +335,12 @@ name of all the templates as an array using the ``with`` keyword:

.. code-block:: html+twig

{% form_theme form with ['::common.html.twig', ':Form:fields.html.twig',
'AppBundle:Form:fields.html.twig'] %}
{% form_theme form with ['common.html.twig', 'form/fields.html.twig'] %}

{# ... #}

The templates can be located at different bundles and they can even be stored
at the global ``app/Resources/views/`` directory.
The templates can also be located in different bundles, use the functional name
to reference these templates, e.g. ``AcmeFormExtraBundle:form:fields.html.twig``.

Child Forms
...........
Expand All @@ -350,16 +349,16 @@ You can also apply a form theme to a specific child of your form:

.. code-block:: html+twig

{% form_theme form.child 'AppBundle:Form:fields.html.twig' %}
{% form_theme form.child 'form/fields.html.twig' %}

This is useful when you want to have a custom theme for a nested form that's
different than the one of your main form. Just specify both your themes:

.. code-block:: html+twig

{% form_theme form 'AppBundle:Form:fields.html.twig' %}
{% form_theme form 'form/fields.html.twig' %}

{% form_theme form.child 'AppBundle:Form:fields_child.html.twig' %}
{% form_theme form.child 'form/fields_child.html.twig' %}

.. _cookbook-form-php-theming:

Expand All @@ -375,9 +374,13 @@ file in order to customize the ``integer_widget`` fragment.

.. code-block:: html+php

<!-- app/Resources/views/Form/integer_widget.html.php -->
<!-- app/Resources/views/form/integer_widget.html.php -->
<div class="integer_widget">
<?php echo $view['form']->block($form, 'form_widget_simple', array('type' => isset($type) ? $type : "number")) ?>
<?php echo $view['form']->block(
$form,
'form_widget_simple',
array('type' => isset($type) ? $type : "number")
) ?>
</div>

Now that you've created the customized form template, you need to tell Symfony
Expand All @@ -388,7 +391,7 @@ tell Symfony to use the theme via the ``setTheme`` helper method:

.. code-block:: php
<?php $view['form']->setTheme($form, array('AppBundle:Form')); ?>
<?php $view['form']->setTheme($form, array(':form')); ?>
<?php $view['form']->widget($form['age']) ?>
Expand All @@ -401,7 +404,14 @@ method:

.. code-block:: php
<?php $view['form']->setTheme($form['child'], 'AppBundle:Form/Child'); ?>
<?php $view['form']->setTheme($form['child'], ':form'); ?>
.. note::

The ``:form`` syntax is based on the functional names for templates:
``Bundle:Directory``. As the form directory lives in the
``app/Resources/views`` directory, the ``Bundle`` part is empty, resulting
in ``:form``.

.. _cookbook-form-twig-import-base-blocks:

Expand Down Expand Up @@ -475,8 +485,8 @@ Twig
~~~~

By using the following configuration, any customized form blocks inside the
``AppBundle:Form:fields.html.twig`` template will be used globally when a
form is rendered.
``form/fields.html.twig`` template will be used globally when a form is
rendered.

.. configuration-block::

Expand All @@ -485,14 +495,14 @@ form is rendered.
# app/config/config.yml
twig:
form_themes:
- 'AppBundle:Form:fields.html.twig'
- 'form/fields.html.twig'
# ...

.. code-block:: xml
<!-- app/config/config.xml -->
<twig:config>
<twig:form-theme>AppBundle:Form:fields.html.twig</twig:form-theme>
<twig:form-theme>form/fields.html.twig</twig:form-theme>
<!-- ... -->
</twig:config>
Expand All @@ -501,7 +511,7 @@ form is rendered.
// app/config/config.php
$container->loadFromExtension('twig', array(
'form_themes' => array(
'AppBundle:Form:fields.html.twig',
'form/fields.html.twig',
),

// ...
Expand Down Expand Up @@ -677,7 +687,7 @@ customize the ``name`` field only:
.. code-block:: html+php

<!-- Main template -->
<?php echo $view['form']->setTheme($form, array('AppBundle:Form')); ?>
<?php echo $view['form']->setTheme($form, array(':form')); ?>

<?php echo $view['form']->widget($form['name']); ?>

Expand Down Expand Up @@ -735,7 +745,7 @@ You can also override the markup for an entire field row using the same method:
.. code-block:: html+php

<!-- Main template -->
<?php echo $view['form']->setTheme($form, array('AppBundle:Form')); ?>
<?php echo $view['form']->setTheme($form, array(':form')); ?>

<?php echo $view['form']->row($form['name']); ?>

Expand Down
36 changes: 8 additions & 28 deletions cookbook/security/entity_provider.rst
Expand Up @@ -422,20 +422,18 @@ both are unique in the database. Unfortunately, the native entity provider
is only able to handle querying via a single property on the user.

To do this, make your ``UserRepository`` implement a special
:class:`Symfony\\Component\\Security\\Core\\User\\UserProviderInterface`. This
interface requires three methods: ``loadUserByUsername($username)``,
``refreshUser(UserInterface $user)``, and ``supportsClass($class)``::
:class:`Symfony\\Bridge\\Doctrine\\Security\\User\\UserLoaderInterface`. This
interface only requires one method: ``loadUserByUsername($username)``::

// src/AppBundle/Entity/UserRepository.php
namespace AppBundle\Entity;

use Symfony\Bridge\Doctrine\Security\User\UserLoaderInterface;
use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Security\Core\User\UserProviderInterface;
use Symfony\Component\Security\Core\Exception\UsernameNotFoundException;
use Symfony\Component\Security\Core\Exception\UnsupportedUserException;
use Doctrine\ORM\EntityRepository;

class UserRepository extends EntityRepository implements UserProviderInterface
class UserRepository extends EntityRepository implements UserLoaderInterface
{
public function loadUserByUsername($username)
{
Expand All @@ -456,30 +454,12 @@ interface requires three methods: ``loadUserByUsername($username)``,

return $user;
}

public function refreshUser(UserInterface $user)
{
$class = get_class($user);
if (!$this->supportsClass($class)) {
throw new UnsupportedUserException(
sprintf(
'Instances of "%s" are not supported.',
$class
)
);
}

return $this->find($user->getId());
}

public function supportsClass($class)
{
return $this->getEntityName() === $class
|| is_subclass_of($class, $this->getEntityName());
}
}

For more details on these methods, see :class:`Symfony\\Component\\Security\\Core\\User\\UserProviderInterface`.
.. versionadded:: 2.8
The :class:`Symfony\\Bridge\\Doctrine\\Security\\User\\UserLoaderInterface`
was introduced in 2.8. Prior to Symfony 2.8, you had to implement
``Symfony\Component\Security\Core\User\UserProviderInterface``.

.. tip::

Expand Down
Expand Up @@ -7,7 +7,6 @@ empty class, you might be tempted to move some code from the front controller
to it::

// example.com/src/Simplex/Framework.php

namespace Simplex;

use Symfony\Component\Routing;
Expand All @@ -33,7 +32,6 @@ to it::
The front controller code would become more concise::

// example.com/web/front.php

require_once __DIR__.'/../vendor/autoload.php';

use Symfony\Component\HttpFoundation\Request;
Expand Down Expand Up @@ -94,7 +92,6 @@ container:
Create a new file to host the dependency injection container configuration::

// example.com/src/container.php

use Symfony\Component\DependencyInjection;
use Symfony\Component\DependencyInjection\Reference;

Expand Down Expand Up @@ -147,7 +144,6 @@ it in other object definitions.
The front controller is now only about wiring everything together::

// example.com/web/front.php

require_once __DIR__.'/../vendor/autoload.php';

use Symfony\Component\HttpFoundation\Request;
Expand All @@ -165,7 +161,6 @@ As all the objects are now created in the dependency injection container, the
framework code should be the previous simple version::

// example.com/src/Simplex/Framework.php

namespace Simplex;

use Symfony\Component\HttpKernel\HttpKernel;
Expand Down

0 comments on commit ae53c89

Please sign in to comment.