You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.
In the future, we will likely support mappings where the order of mappings becomes important. Here are a couple of examples of possible scenarios where this may come into play:
A target element that needs to have the same value as a previous mapping, but where that previous mapping was a complex combination of multiple transformations that the user didn’t want to have to recreate every time that value is desired. Thus, the user would want either someway to save the first mapping transformation result in a variable (possibly the properties already supported? Our current Eclipse mapper allows for this via what we call variables.), or have some type of “copy” action available that would basically treat a previous mapping as a source for a later mapping.
Decision logic is involved in a target mapping that considers the results of previous mappings, again assuming considering just the source in the decision is too difficult due to the complexity of the transformations that created the previous target values.
So the concern is we should consider this likelihood in the UI design to hopefully avoid any jarring change to the user experience in the future when this support is realized.
The text was updated successfully, but these errors were encountered:
In the future, we will likely support mappings where the order of mappings becomes important. Here are a couple of examples of possible scenarios where this may come into play:
A target element that needs to have the same value as a previous mapping, but where that previous mapping was a complex combination of multiple transformations that the user didn’t want to have to recreate every time that value is desired. Thus, the user would want either someway to save the first mapping transformation result in a variable (possibly the properties already supported? Our current Eclipse mapper allows for this via what we call variables.), or have some type of “copy” action available that would basically treat a previous mapping as a source for a later mapping.
Decision logic is involved in a target mapping that considers the results of previous mappings, again assuming considering just the source in the decision is too difficult due to the complexity of the transformations that created the previous target values.
So the concern is we should consider this likelihood in the UI design to hopefully avoid any jarring change to the user experience in the future when this support is realized.
The text was updated successfully, but these errors were encountered: