Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
2.0.0-M5
-
None
-
None
Description
In v2 we support meta-annotations, which can then have both Isis and also JDO annotations against them. That will make for better modularity.
What's not clear right now is whether it's worth the boilerplate without an actual use case to benefit from that boilerplate. The only use case in practice in many cases is for a string property, eg name, where we want to tell both Isis and JDO that the max length is 50, say.
Another use case could be for regex's, eg for a reference. That is the beginning of some business logic, and could use @Property(regexPattern=...) and @parameter(regexPattern=...).
More generally, we can do @Property(mustSatisfy=...) and @parameter(mustSatisfy=...) for arbitrary business logic.
Another consideration is if the property appears as a parameter in lots of actions; in which case this allows having to specify @Parametr and @ParameterLayout everywhere.
For this particular use case, suggest just inline and get rid of NameType ("yagni" - "you ain't gonna need it", in other words).
Perhaps the tipping point is if we could see there being a value type in the future... in which case a meta-annotation as being fairly close to that. Whether a value type / meta-annotation is worth the overhead depends on a couple of factors: one might be whether the concept itself is helpful to have as part of the ubiquitous language, another more practical reason is whether the entities that have properties of that value type are mutable (for that value type): eg does a Fixed Asset's name ever change? If so, a value type for 'Name' might start to make sense.
I prefer using standards first and foremost, e.g. i would recommend switching to java bean validation which has default annotations for this. It has strong spring boot support, see https://reflectoring.io/bean-validation-with-spring-boot/ Hence for String length validation use annotation @size(max=50) for regex use annotation @pattern(regexp = "^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$") for business logic in the entity use @AssertTrue or @AssertFalse and of course one can define custom (generic) annotations.
We could certainly do this, though would require a contribution to Apache Isis itself to 'teach' it about the meanings of this. I think this would be a good and discrete thing to look into.
Indeed, we do still have (very old) tickets for this:
fyi, as a matter of style, we did use to have lots of fine-grained annotations similar to @size and @pattern. The difficulty we found was remembering them all, which is why we switched to using two annotations (one domain, one layout) for each member type ... ie @Property/@PropertyLayout, @action/@ActionLayout etc.
Ok, to summarize my take on this:
- Use java bean validation for validation of business logic (the java standard for validations) in combination with Spring for additional ease of use.
- Refactor Apache Isis to support Java Bean Validation (so both Ises and ORM understand the same annotations)
- Add @Property(Layout) and @action(Layout) as custom Java Bean validation annotations
Attachments
Issue Links
- contains
-
CAUSEWAY-517 ??? Support JSR-305 annotations (@Immutable, @Signed, @MatchesPattern)
-
- Closed
-
-
-
- Open
-