Added case insensitive fields mapping #18
Conversation
Feature/case insenstive
|
Hi, @smotastic what's your approach to unit testing mapper generator? It works locally, with paths instead of version in pubspec.yaml. |
|
Hi @Antriadus , first of all I like the feature. Let's see if we can make the tests work again. I think it has to do with the updated version. I would suggest going back to 1.1.3, and referencing the local smartstruct annotations in your generator pubspec. Then the tests in the smartstruct_generator will resolve the local version of the smartstruct package. I will then, for my release update the version accordingly in both packages. And as soon as I published it on pub.dev, the generator should be fine for having 1.1.4 in its dependencies too. |
|
Please check now |
|
Hi, the tests look good now. |
…o feature/custom-field
Feature/custom field
|
|
||
| class Target { | ||
| final String fullName; | ||
| final DateTime birthDate; |
There was a problem hiding this comment.
Only constructor parameters are paid attention to by the generator.
If i change the Target class in the example custom_mapping.dart to the following.
class Target {
final String fullName;
DateTime? birthDate;
final String avatar;
Target(
this.fullName,
this.avatar,
);
}With the custom mapping of birthdate (not changed)
@Mapper()
abstract class CustomMapper {
@DateTimeFromSourceMapper(targetField: "birthDate", f: mapBirthDate)
@CustomMapping(targetField: "fullName", f: mapFullName)
Target fromSource(Source source);
}The birthDate is ignored by the generator.
| /// | ||
| /// Annotate the method with [CustomMapping] and provide a valid targetField and mapping function f | ||
| /// To achive type safety, override CustomMapping class with specific TargetField and SourceClass types | ||
| class CustomMapping<TargetField, SourceClass> { |
There was a problem hiding this comment.
Is it possible to extend the Mapping Annotation, instead of writing a new CustomMapping Annotation?
Basically it's an enhanced Mapping(...), because instead of mapping the target to another source property, we are mapping the target to another method.
The generator could just check if the source argument is available as a property in the Source Parameter, and if not check if there is a method and use this instead
| /// | ||
| /// Annotate the method with [CustomMapping] and provide a valid targetField and mapping function f | ||
| /// To achive type safety, override CustomMapping class with specific TargetField and SourceClass types | ||
| class CustomMapping<TargetField, SourceClass> { |
There was a problem hiding this comment.
Right now it's not possible to support multiple source parameters in the custom mapping annotation.
This is currently not supported by the mapper anyway, but planned in the future (#7)
so it would be nice if the customMapping would already support this (but not using it right now).
This also means, if we will have a dynamic amount of source parameters, we cannot define a static amount of parameters in the CustomMapping,
but dynamic is also not possible via generics.
So my first idea would be to not pass the custom mapping method as a parameter itself, but only the name of the method.
Something like
@Mapper()
abstract class CustomMapper {
@CustomMapping(targetField: "fullName", f: 'mapFullName')
Target fromSource(Source source);
}The Mapper then could easily locate the method by it's name and just pass all source parameters which are available.
Alternatively we could define multiple CustomMapping Annotations like CustomMapping1, CustomMapping2, ..., which would then accept a multiple amount of source parameters,
but this sounds a little dirty and probably more complex to handle when we are reading them.
No description provided.