Skip to content

Conversation

@mflorea
Copy link
Member

@mflorea mflorea commented Feb 10, 2026

Jira URL

https://jira.xwiki.org/browse/XRENDERING-803

Changes

Description

Adds two methods to the TransformationContext:

TransformationContext#setTransformationNames(List<String>)
TransformationContext#getTransformationNames()

Updates the DefaultTransformationManager to take into account the new context information.

Clarifications

This is needed for the new $services.rendering.transform() API that will allow specifying the list of transformations to execute.

Expected merging strategy

  • Prefers squash: Yes
  • Backport on branches:
    • N/A

…ns to execute from the transformation context
@mflorea mflorea requested review from tmortagne and vmassol February 10, 2026 16:53
@mflorea mflorea self-assigned this Feb 10, 2026
…ns to execute from the transformation context

* Providing an empty list should skip the transformation execution.
* Use Optional to make it more clear that the list might not be set on the transformation context.
* @since 18.1.0RC1
*/
@Unstable
public Optional<List<String>> getTransformationNames()
Copy link
Member

Choose a reason for hiding this comment

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

I'm curious about the usage of "names" vs "id". AFAIU you'd pass technical id (and more specifically transformation component hints). I consider name to be something more UI-oriented, for users.

WDYT?

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 don't have a strong preference, but I wanted to be consistent with the existing RenderingConfiguration#getTransformationNames() that you introduced some years ago :) see 7a396c3#diff-51d5d538d396a9b28f1f6cf6072df259c6d8437a075bf6ee1805c88a7e9d44ae .

Copy link
Member

@vmassol vmassol Feb 11, 2026

Choose a reason for hiding this comment

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

hehe touché :)

So indeed we need to decide between consistency or correctness. Hard choice. I personally prefer correctness (so that the software/API improves over time) but I'm also ok to keep the consistency, so I think it's fine to keep it as you did, unless some other devs think we should change it.

Thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants