Hi!
This posting is spawned from from thread “Hibernate and RM”. It deviates from that thread in the sense that it does not directly concern the DbC discussion there.
Domain models like the openEHR-RM often throw errors/exceptions (from custom written error checking code or from DbC frameworks) if treated in bad ways (being called with nulls, bad values/formats etc). These errors/exceptions are usually aimed at other developers and this is OK since it is probably developers (not the end users) that should be fixing the errors the calling code is causing. So do not interpret this as criticism of the current implementation, rather a suggestion to extend/enhance the code to support another level of error/validating reporting targeted to end users.
One could argue that validating user input is the job of GUI programmers not domain model programmers - another position is to say that it doesn’t hurt if the domain model can support the GUI code etc in this task, thus making the GUI code simpler and less error prone. If validation can be supported by the domain model without hurting usability and performance of other ( e.g. non-GUI) code it might be interesting to consider. If we separate what is intended for end users (at production runtime) and for developers (things that should be detected during development/testing) both validation/checking-mechanisms might become easier to develop and maintain.
In the ‘Spring’ framework validation is dealt with in an interesting way, see section 16.3 in the document https://springmodules.dev.java.net/docs/reference/0.7/pdf/springmodules-docs-reference.pdf that describes the “Bean Validation Framework”. Spring seems to be well maintained and up to date regarding java versions. The intention seems to be validating user input, so there are built in options to return error codes, error messages etc that can be shown by a GUI. Most interesting regarding implementation would probably be section MailScanner has detected a possible fraud attempt from “16.3.2.4” claiming to be MailScanner warning: numerical links are often malicious: 16.3.2.4. that describes a format using java annotations that does not introduce annoying extra XML files.
It is worth to note (in the documentation above) that in addition to the built in validators custom validators could be added. In addition to openEHR-RM-specific validators where the predefined ones do not suffice - maybe also archetype-aware validators could be suitable. I have not researched this properly, but one could hope that it would be possible to create an archetype-aware validator that also checks the archetyped constraints in suitable use case scenarios.
Another document about validation in the Spring framework is: http://www.springframework.org/docs/reference/validation.html
Validation has been proposed as an addition to java (probably version 7) so it is not a Spring-specific thing we are discussing, see:
http://jcp.org/en/jsr/detail?id=303
http://www.infoq.com/news/JSR303-validation-standard
Hibernate has very similar annotations… (many seem to be identical)
http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html
…so if we would use something like the Spring Bean Validation Framework even some database validation setup might become supported by the RM.
I am not suggesting that user input validation additions to the kernel should be introduced today, just that we should have it “on the radar” for the future.
Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/