https://kotlinlang.org logo
Join Slack
Powered by
I have a question, and I have no other place to as...
# akkurate
c
I have a question, and I have no other place to ask it than here... I wonder if anyone has also run into this, or maybe even has an answer for this. Say we have a dto that backs a form submission:
Copy code
data class Person(val name: String?, val dateOfBirth: LocalDate?) {
  fun validate(): ValidationResult { ... }
}
When we submit an empty form 
name
and 
dateOfBirth
are 
null
. Say this is fine for 
dateOfBirth
(it's not a required field) and 
name
fails validation. So we present the user with the validation errors and allow 'm to try again. Now user submits again with a 
name
and the dto validates. Only all the required fields (in this case only one) are still nullable! So mapping the dto to db records (we use jOOQ for that) we have a lot of `!!`s, i.e. 
record.name = dto.name!!
. Ideally I'd like the validate method to return a 
ValidatedPerson
data class which has all required fields marked as non-nullable. And the only way I can imagine to have this, is by doing A LOT of boiler plate: defining the ``ValidatedPerson`` myself, mapping to it by hand, etc. This is so much work that I rather do the `!!`s on the mapping to the record. Like I said: just curious is you are doing something similar to me, or have found another way to handle this.
j
For me, 
name
should'nt be nullable since its not optional. If the form is sent without filing 
name
, you should receive an empty string and it should fail validation. Bonus: • You don't have to check for null and empty to check if the name is invalid. • You don't have to cast the value.
However, I did thought about applying this pattern to Akkurate, but it's not something planned at the moment and it might never happen.
c
@Johann Pardanaud thanks for chiming in! Good feedback.
👍 1
d
Just a thought @Johann Pardanaud, your referring to that pattern of parsing could maybe be using annotations on factory functions to create validators instead of on the data class itself, and then such a validator could require some kind of mapper to return the parsed class... this kind of pattern could also be used on classes representing requests that need to be validated and then mapped to another class for use...?
It wouldn't be a trivial change though, especially if the user would need to receive the validated values to map...
This seems to be an older implementation of this kind of concept: https://github.com/sksamuel/tribune
👍 1
But with kmp, it could be much simpler...
j
Honestly, I am not planning to implement that, it is way to cumbersome. However, its a really interesting
d
Now that I think of it, all that might really be missing is generation of a mapper function with all the validated fields as parameters to a lambda that maps to a type 
R
...
☝️ 1
On a successful validation, the mapper function could be used to do the mapping to whatever the user wants. That's assuming that there's an Input class and a class to map to
I guess the real problem is how to guess the result types...
Since the validator creation is at run time
Unless 
@Validate(mapTo = SomeStrictTypedClass::class)
But that would really have to create certain base validations with the mapping function to assure that everything passes before mapping
j
I think this is out of scope for Akkurate. It could be implemented by using something like Mapstruct instead
d
Yeah, java and kapt again 🤷🏼‍♂️
j
Yeah, it would be awesome to have a good Kotlin alternative because this library is awesome.
d
But it seems to do that amongst same types.. it has isomorphic type mapping, but it's not for what we're talking about
a
We are using Mapstruct for this purpose. We also use it to map DTOs to mutable Hibernate-Entities (to stay compatible with the legacy code, which uses mutable entities all the time >.< )
3 Views
Open in Slack
PreviousNext
Powered by