stephenh / dtonator Goto Github PK

Perhaps I'm just being dense, but I can not seem to figure out where this project expects to find the dtonator.yaml config. In the features example, I can see that the file is located in the src/main/java folder, but when I try that with my project I keep getting the error "org.yaml.snakeyaml.error.YAMLException: java.io.IOException: Stream closed" when I try to run. Is there something I'm missing?

We use lombok extensively, i wish those auto generated DTOs can include some lombok annotations such as @DaTa, @AllArgsConstructor, @NoArgsConstructor, @builder, etc.If i have manually add them, i wish i just need to add once, next time auto generated DTOs will not overwrite my manually update DTO class.

Is there any current support for generic typed properties?

While I was working on another issue, I happened to run across the javaparser library (https://github.com/javaparser/javaparser). This library seems ideal both for parsing the structure of the domain classes and for building the corresponding DTOs. What do you think of using this library (or something similar) as a replacement for the string interpolation currently being handled by joist?

do i need to add maven dependency to use this tool in Intellij? i couldn't find it from maven central.

While the generation process can handle properties of type java.util.List, there is no equivalent support for java.util.Set.

The 'isEntity()' and 'isDomainObject()' method of the DtoConfig class appear the have their names reversed. 'isEntity()' is currently checking the package of the domain class and 'isDomainObject()' is looking for an 'id' property.

The generation of the DTO classes produces results with invalid syntax for DTOs with inheritance, where the 'properties' config is not explicitly set. If the properties config is missing, the copyOf method of the child DTO will be invalid. If the properties config is set to '*' the constructor of the child class will have duplicate parameters.

example configs from dtonator-features:

Working

AccountDto:
  domain: Account
  properties: id, name
  tessellModel: true
  forceMapperMethods: name

RedAccountDto:
  extends: AccountDto
  domain: RedAccount
  properties: foo
  tessellModel: true

Invalid 'copyOf'

AccountDto:
  domain: Account
  tessellModel: true
  forceMapperMethods: name

RedAccountDto:
  extends: AccountDto
  domain: RedAccount
  tessellModel: true

Duplicate Constructor Parameters

AccountDto:
  domain: Account
  properties: '*'
  tessellModel: true
  forceMapperMethods: name

RedAccountDto:
  extends: AccountDto
  domain: RedAccount
  properties: '*'
  tessellModel: true

Currently, dto properties will be generated for all methods that follow the T getX() or setX(T t) pattern. This includes 'generator' methods where the property does not correspond to and field of the domain class. For example, given the class

public class Brother {
  public Long id;
  public String getGender() {
    return "male";
  }
}

the generated DTO will have two properties;

Long id

and

String gender

.

In a simple case like this the behavior is harmless. It becomes a problem however if the domain getter performs an expensive operation like a database query. There is also the potential for conflicts with mapping references as Ids.

Is this the expected behavior, and if so would it be worthwhile to have a config setting to allow the user to include/exclude these properties?