Page MenuHomePhabricator

Consider making the "itemwise" property of TransformationDefinition optional
Closed, ResolvedPublic

Description

In specifying a translation template definition, it is expected that transformation steps have, in addition to they type and config properties, an itemwise property indicating whether transformation must be applied to individual items in an input array independently, or to the entire array as a whole.

Each transformation type supports both, but has one preferred. For example, if an array of two or more items is passed to a Split transformation step, the default behavior is to apply transformation item-wise. Whereas if it is passed to a Join transformation step, the most likely preferred behavior is that it is applied to the array as a whole.

In addition, it may be confusing for users to decide whether a transformation step should be applied item-wise or not, and usually they would be OK with using the default behavior.

Therefore, consider setting the itemwise property of the TransformationDefinition interface as optional, and use the default setting for each transformation type if unset.

Event Timeline

In the meantime, added the default value to the Early adopter guidelines (here), and to the templates.json schema (this commit).

Because transformation step types are defined within a oneOf object in the templates json schema, the default value of the itemwise property is not being used (actually, the editor uses the one corresponding to the first transformation step type, but then doesn't overwrite the value when another type is chosen). This is probably related to this bug in json-editor.

As a workaround, adding the default itemwise value as info text, to each of the transformation step types (659ce137).

diegodlh claimed this task.
diegodlh moved this task from Backlog to Done on the Web2Cit-Core board.

Because transformation step types are defined within a oneOf object in the templates json schema, the default value of the itemwise property is not being used

I fixed it with the keep_oneof_values: false option.

I will close this for now, as it seems to me it is no longer necessary to mark this as an optional field.