[
https://issues.apache.org/jira/browse/BEAM-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677988#comment-15677988
]
Scott Wegner commented on BEAM-767:
-----------------------------------
After chatting with @lukecwik, we decided that it was confusing to have a
.nested(..) operation which does two things (effectively .add(key,
comp.getClass()).include(key, comp)). We thought it would be surprising to have
an automatically-added class item. Furthermore, the display data API today is
purely additive, and it was confusing having configuration that could configure
and subtract in the same fluent API
(.nested(..).withLabel(..).withoutClassItem()).
We concluded that the current API is preferable because it is easier to
understand and use, albeit being more syntax.
> Add DisplayData builder '.nested(..)' operation
> -----------------------------------------------
>
> Key: BEAM-767
> URL: https://issues.apache.org/jira/browse/BEAM-767
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Scott Wegner
> Assignee: Scott Wegner
> Fix For: Not applicable
>
>
> See: https://github.com/apache/incubator-beam/pull/1088#discussion_r83332515
> In the Java SDK, components can register display data directly, as well as
> include display data from sub-components via the 'include(..)' operation. In
> [PR #1008|https://github.com/apache/incubator-beam/pull/1088], we add 'paths'
> to display data metadata and also include a 'delegate(..)' action.
> During the change for paths, we noticed an emerging pattern where components
> will typically add the .getClass() of a subcomponent before including it. We
> can support this convention better by embedding it in a single configurable
> operation, '.nested(..)'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
