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

[Feature] Property validation #354

Open
gamerover98 opened this issue Aug 17, 2023 · 1 comment
Open

[Feature] Property validation #354

gamerover98 opened this issue Aug 17, 2023 · 1 comment
Milestone

Comments

@gamerover98
Copy link
Contributor

Description

Some Java frameworks, such as Spring Boot, provide comprehensive Java Bean Validation support for checking the values of DTOs, Entities, and more.

public class PersonForm {
  @NotNull
  @Size(max=64)
  private String name;
  
  @Min(0)
  private int age;
}

The current version of ConfigMe lacks these capabilities and makes the data checking annoying.


Scenario

  1. A SettingHolder class with different properties such as:
@Size(max=32)
@Comment("The text of the title")
public static final Property<String> TITLE_TEXT =
    newProperty("title.text", "-Default-");

@Size(min=1, max=10)
@Comment("The size that the title will have")
public static final Property<Integer> TITLE_SIZE =
    newProperty("title.size", 7);
  1. A bean class:
public class EntityBeanProperty implements ParameterizedType {

  private static final Type[] TYPE_ARGUMENTS = {
    Boolean.TYPE, // enabled or disabled
    Integer.TYPE, // number of entities
    ...
  };
  
  private boolean enabled;
  
  @Size(min=0, max=16)
  private int entities;
  
  // constructors...
  // getters/setters...
  // other stuff...
  
  @Override
  public Type[] getActualTypeArguments() {
      return TYPE_ARGUMENTS;
  }
  
  @Override
  public Type getRawType() {
      return EntityBeanProperty.class;
  }
  
  @Override
  public Type getOwnerType() {
      return null;
  }
}

Please note that this issue is a draft and may undergo changes.


Looking forward to your feedback and collaboration on this enhancement.
Thank you 💯

@ljacqu
Copy link
Member

ljacqu commented Aug 17, 2023

Many years ago, I had the same idea in #14 and ultimately felt it was too broad for the benefits:

  • I think properties with a defined value range can be defined as separate property type (Int property within range #330). If I need to use the same range in many places I can easily make a helper method and even give it a semantic name, such as PercentageProperty
  • Adding support for a validation framework's annotations means we should support all annotations and keep up-to-date with it. Not sure I want to commit to that.
  • At least for my personal usages of ConfigMe, if I do have more complex validations than just a number range, I'd want to have manual control over it so I can log stuff for the user, etc. I feel that many validation cases would be served by having validations in some class and calling it after ConfigMe is set up. Just by receiving ConfigMe's SettingsManager, that validation service can access the properties' current and default values, can change the values and retrigger a save.

This is not a definitive no from my side but my current feeling. I'm currently rewriting the way property types are structured so this is anyway blocked for a while, giving us time to consider all aspects 😄

(Btw, you probably don't want to implement ParameterizedType in that example, but just have a bean class and then use the BeanProperty constructor that takes a Class argument. ParameterizedType is a generic type declaration for something like List<String>, where the base type would be List.class and the type arguments in this example would be {String.class})

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants