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
Is your feature request related to a problem? Please describe.
We currently mostly use the auto mapping together with the NameAttribute when generating CSV files. It works very well with the customized column names, except when we have nested DTO references. In that case we currently can only access the member name and type but not the MemberInfo itself, which could be used to find more informations about the parent property.
For example, if we consider the following data classes:
By using the ReferenceHeaderPrefix setting, we currently can not detect, which property we're currently generating the prefix for. (e.g. "Foo.MyCustomName" or "Bar.MyCustomName")
Describe the solution you'd like
If the current MemberInfo instance would be added to the ReferenceHeaderPrefixArgs, we would gain more options to generate prefixes. For example, we could search the members NameAttribute or do other work with reflection code.
This would allow for a more powerful way to still mostly use automatic mapping with some minimal configuration via attributes.
Describe alternatives you've considered
Otherwise we would have to stop using the automatic mapping, which currently otherwise works great for our use case.
Additional context
As far as I can tell, do all locations which instantiate a ReferenceHeaderPrefixArgs object currenlty have access to the current MemberInfo object.
What I currently don't know is, how prefixes of references nested deeper than 1 layer currently react to this.
Thank you for your consideration.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We currently mostly use the auto mapping together with the
NameAttribute
when generating CSV files. It works very well with the customized column names, except when we have nested DTO references. In that case we currently can only access the member name and type but not the MemberInfo itself, which could be used to find more informations about the parent property.For example, if we consider the following data classes:
By using the
ReferenceHeaderPrefix
setting, we currently can not detect, which property we're currently generating the prefix for. (e.g. "Foo.MyCustomName" or "Bar.MyCustomName")Describe the solution you'd like
If the current MemberInfo instance would be added to the
ReferenceHeaderPrefixArgs
, we would gain more options to generate prefixes. For example, we could search the membersNameAttribute
or do other work with reflection code.This would allow for a more powerful way to still mostly use automatic mapping with some minimal configuration via attributes.
Describe alternatives you've considered
Otherwise we would have to stop using the automatic mapping, which currently otherwise works great for our use case.
Additional context
As far as I can tell, do all locations which instantiate a
ReferenceHeaderPrefixArgs
object currenlty have access to the currentMemberInfo
object.What I currently don't know is, how prefixes of references nested deeper than 1 layer currently react to this.
Thank you for your consideration.
The text was updated successfully, but these errors were encountered: