Patrick Deenen created ISIS-2695:
------------------------------------
Summary: Add Java Bean Validation support
Key: ISIS-2695
URL: https://issues.apache.org/jira/browse/ISIS-2695
Project: Isis
Issue Type: Improvement
Components: Isis Applib (programming model), Isis Core, Isis
Persistence JDO, Isis Persistence JPA
Affects Versions: 2.0.0
Reporter: Patrick Deenen
[~danhaywood]
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|https://issues.apache.org/parameter](regexPattern=...).
More generally, we can do @Property(mustSatisfy=...) and
[@parameter|https://issues.apache.org/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.
[~ppjdeenen]
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|https://issues.apache.org/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.
[~danhaywood]
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:
* https://issues.apache.org/jira/browse/ISIS-491
* https://issues.apache.org/jira/browse/ISIS-517
fyi, as a matter of style, we did use to have lots of fine-grained annotations
similar to [@size|https://issues.apache.org/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|https://issues.apache.org/action]/@ActionLayout etc.
[~ppjdeenen]
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|https://issues.apache.org/action](Layout)
as custom Java Bean validation annotations
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
