Does anyone have the history on why Validateable &...
# questionsj
jdaugherty
10/31/2024, 5:55 PMDoes anyone have the history on why Validateable & GormValidateable don't have a common interface between them?
j
jeffscottbrown
10/31/2024, 7:18 PMI think so. I am in meeting away from keyboard. Will respond later.
❤️ 1
jeffscottbrown
10/31/2024, 8:14 PMI looked at the history to refresh my memory and now I am not sure. I know that the validation process for an entity is different than the validation process for any other Validateable and much of the Entity specific stuff is in GormValidationApi. GormValidateable delegates to that for the real validation work. What I don't recall is why we didn't allow for more reuse across those. I think they probably could have a common interface between them. I am sorry that isn't much help.
j
jdaugherty
11/01/2024, 3:15 AMThank you.
m
moogtrain
11/01/2024, 3:17 PMFWIW, I would prefer it to be split. Constraints mapping for GORM involves setting up entities vs constraints mapping on plain Validateable used for forms. For instance, “nullable”/“unique” for GORM sets up nullness/unique keys of a table column, while on plain form validation it only checks the value when you call validate. These are clearly two different behaviours.
moogtrain
11/01/2024, 3:28 PMIIRC, the split was done around the time when GORM was being made to be able to be used standalone without Grails. I don’t know the exact reason but I think maybe it didn’t make sense for standalone GORM to also carry all of the web validation and type converter bits that were previously coupled together?
👍 1
j
jdaugherty
11/01/2024, 3:29 PMI was thinking something more simple then that - just a common interface without having to bring along all of the dependencies.
jdaugherty
11/01/2024, 3:29 PMthat way if you want to take something that can validate, you can use that interface instead of just def
m
moogtrain
11/01/2024, 3:39 PMSounds like it would easily lead to a diamond problem, with Grails domain object binding on controllers.
j
jdaugherty
11/01/2024, 3:40 PMWhat's odd is there's already shared methods between them:
• getErrors()
• hasErrors()
• validate()
So that's really all I woudl propose. No additional dependencies, and a common base so if you wanted to write code that takes either a gorm validateable or a validateable you could.
👍 2
jdaugherty
11/01/2024, 3:40 PMyou think that would still be a diamond ?
m
moogtrain
11/01/2024, 4:04 PMI see, so it would just be a duck-type interface?
j
jdaugherty
11/01/2024, 4:05 PMExactly
jdaugherty
11/01/2024, 4:05 PMit's better than def or Object everywhere
m
moogtrain
11/01/2024, 4:14 PMI don’t think it’s that big of a deal to be honest. Two of the methods are just getters to a Spring Errors object, so why not just use Errors in your methods. As for validate(), I think of Validateable and GormValidateable have very different execution contexts. If you have one interface, how do I know which one is it?
j
jdaugherty
11/01/2024, 4:16 PMIn my particular case, it's an generic uploader function. You can create domains or commands (and the caller can do whatever it wants with the commands). The duck typing would just allow me to remove Object everywhere.
m
moogtrain
11/01/2024, 4:18 PMFWIW, I am guilty of writing my own wrapper trait over Validateable to:
1. allow merging errors from e.g. a GormValidateable domain object.
2. Extract errors from within lists, since they aren’t Validateable themselves.
So I understand the need.