8000 [Serializer] Add CDATA_WRAPPING_NAME_PATTERN support to XmlEncoder by Deltachaos · Pull Request #60355 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Serializer] Add CDATA_WRAPPING_NAME_PATTERN support to XmlEncoder #60355

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&r 8000 dquo;, 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

Jump to bottom
Open
wants to merge 1 commit into
base: 7.3
Choose a base branch
from
Open

[Serializer] Add CDATA_WRAPPING_NAME_PATTERN support to XmlEncoder #60355

wants to merge 1 commit into from

Conversation

Deltachaos
Copy link
Contributor
Q A
Branch? 7.3
Bug fix? no
New feature? yes
Deprecations? no
Issues
License MIT

Add CDATA_WRAPPING_NAME_PATTERN support to XmlEncoder

This PR introduces a new option for the Symfony Serializer component's XmlEncoder: CDATA_WRAPPING_NAME_PATTERN.

While Symfony already provides CDATA_WRAPPING_PATTERN to wrap field content in CDATA based on a regex match, this new feature enables CDATA wrapping based on the field name—regardless of the field's content.

Example use case:

$this->encoder->encode($data, 'xml', [
    XmlEncoder::CDATA_WRAPPING_NAME_PATTERN => '(firstname|lastname)'
]);

This ensures that fields named firstname or lastname are always wrapped in CDATA tags, even if their content doesn't match the typical pattern used by CDATA_WRAPPING_PATTERN.

Motivation:

  • Consistent Output: In many integration scenarios (e.g., with legacy systems, XML consumers, or strict XSD schemas), consumers expect certain fields to always use CDATA sections—even when their content doesn't require escaping. This option allows for deterministic XML output by name.

  • Better Control: It separates concerns: one can now configure CDATA-wrapping for content-based needs and field-based policies B3FE independently.

  • Backward Compatible: The feature is fully optional and does not interfere with existing behavior unless the option is explicitly set.

@Deltachaos Deltachaos requested a review from dunglas as a code owner May 6, 2025 09:16
@carsonbot carsonbot added this to the 7.3 milestone May 6, 2025
@Deltachaos Deltachaos force-pushed the feature/cdata-names branch from ad5bdb6 to 7477348 Compare May 6, 2025 09:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dunglas dunglas Awaiting requested review from dunglas dunglas is a code owner

Assignees
No one assigned
Labels
Feature Serializer Status: Needs Review
Projects
None yet
Milestone
7.3
Development

Successfully merging this pull request may close these issues.
2 participants
@Deltachaos @carsonbot
0