Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitcb31c16

Browse files
committed
Added a new section of tips and tricks to upgrade bundles to Symfony 3.0
1 parent3697d81 commitcb31c16

File tree

1 file changed

+62
-9
lines changed

1 file changed

+62
-9
lines changed

‎cookbook/upgrade/bundles.rst

Lines changed: 62 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -10,8 +10,8 @@ the previous 2.8 version. If your bundle uses any deprecated feature and it's
1010
published as a third-party bundle, applications upgrading to Symfony 3 will no
1111
longer be able to use it.
1212

13-
Allow to Install Symfony 3 Components
14-
-------------------------------------
13+
Allowing to Install Symfony 3 Components
14+
----------------------------------------
1515

1616
Most third-party bundles define their Symfony dependencies using the ``~2.N`` or
1717
``^2.N`` constraints in the ``composer.json`` file. For example:
@@ -46,12 +46,12 @@ The above example can be updated to work with Symfony 3 as follows:
4646
..tip::
4747

4848
Another common version constraint found on third-party bundles is ``>=2.N``.
49-
You should avoid using that constraint because it can wrongly consider as
50-
valid some Symfony versions which are in fact incompatible with your bundle.
51-
Use instead``~2.N|~3.0`` or ``^2.N|~3.0`` to make your bundle future-proof.
49+
You should avoid using that constraint because it's too generic (it means
50+
that your bundle is compatible with any future Symfony version). Use instead
51+
``~2.N|~3.0`` or ``^2.N|~3.0`` to make your bundle future-proof.
5252

53-
Look for Deprecations and Fix Them
54-
----------------------------------
53+
Looking for Deprecations and Fix Them
54+
-------------------------------------
5555

5656
Besides allowing to install Symfony 3 packages, your bundle must stop using
5757
any feature deprecated in 2.8 version, because they are removed (and you'll get
@@ -104,8 +104,8 @@ of deprecated features:
104104
It analyzes Symfony projects to find deprecations. In addition it solves
105105
automatically some of them thanks to the growing list of supported "fixers".
106106

107-
Test your Bundle in Symfony 3
108-
-----------------------------
107+
Testing your Bundle in Symfony 3
108+
--------------------------------
109109

110110
Now that your bundle has removed all deprecations, it's time to test it for real
111111
in a Symfony 3 application. Assuming that you already have a Symfony 3 application,
@@ -158,6 +158,59 @@ following recommended configuration as the starting point of your own configurat
158158
159159
script:phpunit
160160
161+
Updating your Code to Support Symfony 2.x and 3.x at the Same Time
162+
------------------------------------------------------------------
163+
164+
The real challenge of adding Symfony 3 support for your bundles is when you want
165+
to support both Symfony 2.x and 3.x simultaneously using the same code. There
166+
are some edge cases where you'll need to deal with the API differences.
167+
168+
Before diving into the specifics of the most common edge cases, the general
169+
recommendation is to **not rely on the Symfony Kernel version** to decide which
170+
code to use::
171+
172+
if (Kernel::VERSION_ID <= 20800) {
173+
// code for Symfony 2.x
174+
} else {
175+
// code for Symfony 3.x
176+
}
177+
178+
Instead of checking the Symfony Kernel version, check the version of the specific
179+
component. For example, the OptionsResolver API changed in its 2.6 version by
180+
adding a ``setDefined()`` method. The recommended check in this case would be::
181+
182+
if (!method_exists('Symfony\Component\OptionsResolver\OptionsResolver', 'setDefined')) {
183+
// code for the old OptionsResolver API
184+
} else {
185+
// code for the new OptionsResolver API
186+
}
187+
188+
Form Name Refactoring
189+
~~~~~~~~~~~~~~~~~~~~~
190+
191+
.. TODO
192+
193+
- how to check which version to use
194+
- how to update FormType classes
195+
- how to update type service definitions
196+
- how to update FormTypeExtension classes & service definition
197+
198+
OptionsResolver API Refactoring
199+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
200+
201+
.. TODO
202+
203+
- how to check which version to use
204+
- how to both APIs
205+
206+
Service Factory Refactoring
207+
~~~~~~~~~~~~~~~~~~~~~~~~~~~
208+
209+
.. TODO
210+
211+
- how to support both APIs ==> Is there a nice way except from (a) doing
212+
it in the DI extension or (b) creating 2 service definition files?
213+
161214
.. _`symfony/phpunit-bridge package`:https://github.com/symfony/phpunit-bridge
162215
.. _`Official Symfony Guide to Upgrade from 2.x to 3.0`:https://github.com/symfony/symfony/blob/2.8/UPGRADE-3.0.md
163216
.. _`SensioLabs DeprecationDetector`:https://github.com/sensiolabs-de/deprecation-detector

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp