Skip to content

Tweaks after proofreading the 2.6 OptionsResolver stuff #4372

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 28, 2014
Merged

Tweaks after proofreading the 2.6 OptionsResolver stuff #4372

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
d190831
Tweaks after proofreading the 2.6 OptionsResolver stuff
weaverryan Oct 25, 2014
59fd436
Also did a quick proofread
wouterj Oct 25, 2014
f179ec7
A few more tweaks from comments
weaverryan Oct 28, 2014
a1badc5
Renaming a method at the suggestion of my friend Bernhard
weaverryan Oct 28, 2014
b49731b
Linking to the 2.6 headline thanks to a suggestion from @xabbuh
weaverryan Oct 28, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 20 additions & 16 deletions components/options_resolver.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,9 @@
The OptionsResolver Component
=============================

The OptionsResolver component is `array_replace()` on steroids.
The OptionsResolver component is `array_replace()` on steroids. It
allows you to create an options system with required options, defaults,
validation (type, value), normalization and more.

Installation
------------
Expand All @@ -21,7 +23,7 @@ Notes on Previous Versions
.. versionadded:: 2.6
This documentation was written for Symfony 2.6 and later. If you use an older
version, please read the corresponding documentation using the version
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't we just link to the older version (2.5) instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that too, then we could include a link. I can't think of a reason not to do this. Even if they're using 2.3, I don't think there are any differences between 2.3 and 2.5.

drop-down on the upper right.
drop-down on the upper right. For a list of changes, see the `CHANGELOG`_

Usage
-----
Expand Down Expand Up @@ -65,7 +67,7 @@ check which options are set::
}

This boilerplate is hard to read and repetitive. Also, the default values of the
options are buried in the business logic of your code. We can use
options are buried in the business logic of your code. We can use the
:phpfunction:`array_replace` to fix that::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

[...] use the :phpfunction:`array_replace` function to fix that [...]


class Mailer
Expand All @@ -91,10 +93,9 @@ the ``Mailer`` class does a mistake?
'usernme' => 'johndoe',
));

No error will be shown. In the best case, the bug will be appear during testing.
The developer will possibly spend a lot of time looking for the problem. In the
worst case, however, the bug won't even appear and will be deployed to the live
system.
No error will be shown. In the best case, the bug will appear during testing,
but the developer will spend time looking for the problem. In the worst case,
the bug might not appear until it's deployed to the live system.

Let's use the :class:`Symfony\\Component\\OptionsResolver\\OptionsResolver`
class to fix this problem::
Expand Down Expand Up @@ -268,8 +269,8 @@ retrieve the names of all required options::

If you want to check whether a required option is still missing from the default
options, you can use :method:`Symfony\\Component\\OptionsResolver\\OptionsResolver::isMissing`.
The difference to :method:`Symfony\\Component\\OptionsResolver\\OptionsResolver::isRequired`
is that this method will return false for required options that have already
The difference between this and :method:`Symfony\\Component\\OptionsResolver\\OptionsResolver::isRequired`
is that this method will return false if a required option has already
been set::

// ...
Expand Down Expand Up @@ -360,8 +361,8 @@ Value Validation
Some options can only take one of a fixed list of predefined values. For
example, suppose the ``Mailer`` class has a ``transport`` option which can be
one of ``sendmail``, ``mail`` and ``smtp``. Use the method
:method:`Symfony\\Component\\OptionsResolver\\OptionsResolver::setAllowedValues` to verify
that the passed option contains one of these values::
:method:`Symfony\\Component\\OptionsResolver\\OptionsResolver::setAllowedValues`
to verify that the passed option contains one of these values::

// ...
class Mailer
Expand Down Expand Up @@ -470,9 +471,9 @@ Suppose you want to set the default value of the ``port`` option based on the
encryption chosen by the user of the ``Mailer`` class. More precisely, we want
to set the port to ``465`` if SSL is used and to ``25`` otherwise.

You can implement this feature by passing a closure as default value of the
``port`` option. The closure receives the options as argument. Based on these
options, you can return the desired default value::
You can implement this feature by passing a closure as the default value of
the ``port`` option. The closure receives the options as argument. Based on
these options, you can return the desired default value::

use Symfony\Component\OptionsResolver\Options;

Expand Down Expand Up @@ -546,8 +547,10 @@ Options without Default Values
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In some cases, it is useful to define an option without setting a default value.
Mostly, you will need this when you want to know whether an option was passed
or not. If you set a default value for that option, this is not possible::
This is useful if you need to know whether or not the user *actually* set
an option or not. For example, if you set the default value for an option,
it's not possible to know whether the user passed this value or if it simply
comes from the default::

// ...
class Mailer
Expand Down Expand Up @@ -713,3 +716,4 @@ options in your code.

.. _Packagist: https://packagist.org/packages/symfony/options-resolver
.. _Form component: http://symfony.com/doc/current/components/form/introduction.html
.. _CHANGELOG: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/OptionsResolver/CHANGELOG.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make sure that this reference is changed once the 2.6 branch has been created.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this - but I don't think it's necessary, since even the 2.7 or 2.8 CHANGELOG will contain the 2.6 section. So I think we're ok :) That being said, if we remember to change it later, I think that's just fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but once 2.7 is released, you will have to scroll down. ;) We could link to the 2.6 headline in the changelog to avoid this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea! I've just made that change