-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Hello there,
in our project we identified that it would be more beneficial, if we were to use the custom mapper feature that the FSXA-Api exposes. However, we found that it lacks some aspects to make it possible for us to use it efficiently. This mostly concerns convenient access to methods already defined in the CaasMapper-class like the xmlParser, buildPreviewId and mapDataEntries. Some of them we would like to use, but others we would like to override to fit our needs.
I prepared a PR (#20 ) that makes some slight changes which are all backwards-compatible except that I had to add the path as a second argument to the customMapper. It would retain full backwards-compatibility, if the path would be added through the utils-object or as a third parameter. Let me know, which solution you prefer in this regard.
All in all, this PR should just serve to make the feature more usable in general. On future iterations, one could think about exposing even more of the mapper functionality to users. In our project, it would be really useful if we could also override top-level mapping methods like mapElementResponse and mapFilterResponse mostly in order to type them with our internal interfaces and drill them down to the actual use cases we are really employing ourselves. But this would have made the whole setup a bit more convoluted so I chose to settle for the most basic approach.
I would be very happy to know what you think about this or to know how you intended this feature to be used :)