Be able to pre transform or overlay the String value of DataTable before it is converted
See original GitHub issueOriginally, I’m looking to support the needs of being able to resolve a set of values like null. For example,
Given I have a list of Person, configured as follows:
| firstName | lastName |
| Sid | L |
| Kate | [null] |
This can be translated to List<Person>
nicely, if Person class has firstName and lastName field. However, preferred result of Kate’s last name is actually expected to be null
, not literally [null].
For a single value, this could be done with @Transform
to convert null string ([null], null, Null, etc.) into null
. But up to this point, @Transform
doesn’t work with DataTable
. I’m guessing the reason @Transform
is not applicable to DataTable because asList
, and asMap
already does the job through TableConverter
.
However, I can’t seems to find a nice solution to actually solve the above scenario. So I’m thinking that it might be good to make @Transform
applicable to DataTable, but only to do some pre-conversion, more like List<String>
--> List<Person>
, so that users can still benefit from the TableConverter without doing extra works, but still be able to redefine some meaning in the gherkin table.
Proposed Solution
According to the current codebase, I understand that there’s a code in DataTable that converts List<DataTableRow>
into List<List<String>>
, upon its construction.
Would it be a good idea to apply Transformer
class upon this process to resolve the mentioned scenario? I can submit a PR that could help illustrate this.
Alternative Ideas
- Using
@Transform
may be confusing in what it actually does. Maybe something like@Transform(pre = Transformer.class)
- Or may be come up with
@PreTransform
.
Issue Analytics
- State:
- Created 8 years ago
- Comments:8 (2 by maintainers)
Top GitHub Comments
@manat I tip for you would be to reference the issue (with “
#XXX
”) in the PR description instead of in the PR title, then Github picks up the reference and make it visible in the issue in question. Even better is to use a keyword to closing issues (for instance “closes #XXX
”) in the PR description, the Github will close the issue when the PR is merged.This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.