Recommend using form types as data mappers in the docs #11395
Conversation
wouterj
force-pushed
the
issue-11335/data-mapper
branch
from
37a1cf1 to
ab80083
Compare
wouterj
force-pushed
the
issue-11335/data-mapper
branch
from
ab80083 to
f5b6871
Compare
|
Thanks for the review. I've fixed your comments |
|
Thank you Wouter. |
…wouterj) This PR was merged into the 3.4 branch. Discussion ---------- Recommend using form types as data mappers in the docs Fixes #11335 Turns out we did already document implementing the interface in the form type, but only in a small caution at the end. I've swapped it, so we're now using the stateless way in the docs and a small sidebar quickly shows creating a separate data mapper. /cc @mpdude @webmozart Commits ------- f5b6871 Recommend using form types as data mappers in the docs
| .. tip:: | ||
| .. sidebar:: Stateful Data Mappers | ||
|
|
||
| Sometimes, data mappers need to access services or need to maintain their |
There was a problem hiding this comment.
Sometimes, data mappers need to access services
This is actually wrong. When a data mapper needs a service, you can still implement DataMapperInterface in FormType and add the service to the constructor of the form type.
Indeed the only legit reason for creating a separate data mapper class if you want to use form options in the data mapper.
$form = $this->createForm(SomeType::class, $data, ['option_for_data_mapper' => 123]);
Since option values are specific to Form instances and not to the single FormType instance, we need multiple data mappers with different states here. Otherwise you can implement DataMapperInterface in FormType.
There was a problem hiding this comment.
Ah, thanks for clarifying. I was already wondering about the same thing.
Fixes #11335
Turns out we did already document implementing the interface in the form type, but only in a small caution at the end. I've swapped it, so we're now using the stateless way in the docs and a small sidebar quickly shows creating a separate data mapper.
/cc @mpdude @webmozart