Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for concrete class constructor with Mapper(s) parameters #13

Closed
lesaint opened this issue Sep 4, 2014 · 1 comment
Closed
Milestone

Comments

@lesaint
Copy link
Owner

lesaint commented Sep 4, 2014

To implement a clean mapping of a bean tree to another, it is necessary to reference Mapper of lower level bean in the Mappers of higher lever beans.

As such, it is necessary to declare in the concrete class a constructor which takes instance(s) of the lower level bean mappers.

DAMapping does not currently supports this kind of constructors and throws a compilation error.

scope of this issue

For simplicity reasons, support of this feature for concrete classes declaring method(s) annotated with @MapperFactory is out of the scope of this issue. A specific issue will be created.

Although, this feature is blocking writing code mapping trees of beans without using the Spring DI DAMapping support.

Implementation of this issue is a required step to implement DI integration with property injection.

detailed example

Given the following bean trees:

    |---------|                      |---------|
    |   Foo   |                      |   Bar   |
    |---------|                      |---------|
        < >                              < >
         |                                | 
         0                                0 
    |---------|                      |---------|
    |  Footi  |                      |  Barti  |
    |---------|                      |---------|

The expected code for concrete class implementing the mapping from Foo to Bar is a class with a constructor taking the Mapper interface to map Footi to Barti:

@Mapper
public class FooToBar {

  private final FootiToBartiMapper footiToBartiMapper;

  public FooToBar(FootiToBartiMapper footiToBartiMapper) {
    this.footiToBartiMapper = footiToBartiMapper;
  }

  @Nonnull
  public Bar transform(@Nullable Foo foo) {
    // mapping code here
  }
}

implementation

The generated FooToBarMapperImpl class should also have a constructor with the the Mapper interface to map Footi to Barti as a parameter:

public class FooToBarMapperImpl implements FooToBarMapper {
  private final FootiToBartiMapper footiToBartiMapper;

  public FooToBarMapperImpl(FootiToBartiMapper footiToBartiMapper) {
    this.footiToBartiMapper = footiToBartiMapper;
  }

  @Override
  @Nonnull
  public Bar transform(Foo foo) {
    return FooToBarMapperFactory.instance(footiToBartiMapper).transform(foo);
  }

}

The generated FooToBarMapperFactory must take the Mapper interface as a parameter to pass it to the concrete class instance:

class FooToBarMapperFactory {

    public static FooToBar instance(FootiToBartiMapper footiToBartiMapper) {
        return new FooToBar(footiToBartiMapper);
    }

}
@lesaint lesaint added this to the 0.4.0 milestone Sep 4, 2014
lesaint added a commit that referenced this issue Sep 14, 2014
in Mapper method, explicitly use "this." qualifier to call properties to avoid collision with the name of a parameter of the mapper method
also add interface Iterable to FluentIterable to make direct use of the internal Iterable possible without actually creating a List of a Set
lesaint added a commit that referenced this issue Sep 14, 2014
when a dedicated class annotated with @Mapper has at least one type with the ERROR TypeKind, parsing won't failed but will be differed to the end of the round or to all the next round (except the last one)
also all type successfully process and generated are logged so that during differed processing of classes with resolution errors, these resolution errors could be found fixed
if all resolution errors are found fixed, a new parsing of the class annotated with @Mapper is triggered which will now how to fix resolutions reported as errors by Javac

unfortunatly, the algorithm implemented here has drawbacks:
 - can not yet support references to a Mapper which is not in the same package as the class annotated with @Mapper
 - the resolutions are infered based on naming convention (so the solution can hardly evolve to new generated files)
 - we can not yet know which of two classes with the same simpleName is actually referenced by the class annotated with @Mapper
 - if unresolved maper in the class annotated with @Mapper has type arguments or upper/lower bound, they are currently lost
lesaint added a commit that referenced this issue Sep 15, 2014
also fix missing import of annotations on the constructor parameter
@lesaint
Copy link
Owner Author

lesaint commented Sep 16, 2014

feature implemented with the following notes :

@lesaint lesaint closed this as completed Sep 16, 2014
lesaint added a commit that referenced this issue Oct 3, 2014
the integration test was actually written with the dedicated class from another package as a dependency, not the interface generated from it
test was therefor actually useless for the test case it was supposed to cover
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant