Possibility to nest a validator without prefixing the name

[fredrik-forssen-cint]

If I have some objects similar to

public record OtherThing(
    Integer number
) { }

public record Thing(
    OtherThing otherThing
) { } 

And then I have validators for these similar to

public static final Validator<OtherThing> otherThingValidator = ValidatorBuilder.<OtherThing>of()
    .constraint(OtherThing::number, "number", c -> c.notNull().positive())
    .build();

public static final Validator<Thing> thingValidator = ValidatorBuilder.<Thing>of()
    .nest(Thing::otherThing, "", otherThingValidator)
    .build();

Then if I validate an object that looks like

var myThing = new Thing(new OtherThing(-1)); // This will fail due to -1 not being positive

Then the name that ends up in the constraintviolation for this will be .number. I can see why this happens since we are doing .nest, but I was hoping that since we provide "" as the name yavi would omit appending the leading . there. The outcome that I would like to have is to just get number as the name in the constraintviolation.

Is it possible to achieve this and still be able to nest the validators like this?

(Of course, in this simple case you might ask why I dont just put the number directly on the "Thing" object, that would resolve the problem. But in "real life" the objects are larger and contain more fields and I would very much like to separate the validators like this to let me reuse them easier. :) )

[making]

While changing it to remove the "." doesn't seem too difficult, I would consider using reusable and composable validators for such use cases.

[making]

example

import am.ik.yavi.arguments.Arguments1Validator;
import am.ik.yavi.arguments.IntegerValidator;
import am.ik.yavi.builder.IntegerValidatorBuilder;
import am.ik.yavi.core.Validated;

public class Main {

	public static void main(String[] args) {
		Validated<Thing> validated = thingIntegerValidator.validate(-1);
		if (!validated.isValid()) {
			validated.errors().details().forEach(d -> System.out.println(d.getDefaultMessage()));
			// -> "number" must be positive
		}
	}

	static IntegerValidator<OtherThing> otherThingIntegerValidator = IntegerValidatorBuilder
		.of("number", c -> c.notNull().positive())
		.build(OtherThing::new);

	static Arguments1Validator<Integer, Thing> thingIntegerValidator = otherThingIntegerValidator.andThen(Thing::new);

	public record OtherThing(Integer number) {
	}

	public record Thing(OtherThing otherThing) {
	}

}

[fredrik-forssen-cint]

@making Sure, but in that case we're in the ArgumentsXValidator world, right? I havent found a really good way of making that work with the ValidatorBuilder-APIs, it seems (and I may be wrong) that the bridging between those is not trivial (and I cant find how to do it in the docs).

Also, in your example, you are no longer validating the Thing object, you are building the Thing object as you are validating with the number as input. In my case the Thing object comes from deserialized json so it's already constructed at the start. So I dont really want to construct a new object here, I just want to validate the existing one.

[making]

In my case the Thing object comes from deserialized json so it's already constructed at the start. So I dont really want to construct a new object here, I just want to validate the existing one.

thingIntegerValidator.lazy().validated(...) doesn't construct a new object that can be used in a constructor.

[fredrik-forssen-cint]

In my case the Thing object comes from deserialized json so it's already constructed at the start. So I dont really want to construct a new object here, I just want to validate the existing one.

thingIntegerValidator.lazy().validated(...) doesn't construct a new object that can be used in a constructor.

Sorry, I think I may have been a bit unclear with what I meant.
What I meant was that I have

static IntegerValidator<OtherThing> otherThingIntegerValidator = IntegerValidatorBuilder
		.of("number", c -> c.notNull().positive())
		.build(OtherThing::new);

static Arguments1Validator<Integer, Thing> thingIntegerValidator = otherThingIntegerValidator.andThen(Thing::new);

public static void main(String[] args) {
    // This actually is a deserialized json object from jackson so my code doesnt actually new this up explicitly
    // Im just new-ing it up here as an example.
    var thing = new Thing(new OtherThing(-1));

    // Now this line here obviously wont work because the thingIntegerValidator expects the argument to be an Integer, not a Thing
    // and I do not want to pass in thing.otherThing.number directly here, because the object is not validated yet :)
    Validated<Thing> validated = thingIntegerValidator.validate(thing);
}

[making]

If you want to validate when deserializing with Jackson, I would recommend using lazy validation in the constructor.

	static IntegerValidator<OtherThing> otherThingIntegerValidator = IntegerValidatorBuilder
		.of("number", c -> c.notNull().positive())
		.build(OtherThing::new);

	public record OtherThing(Integer number) {
		public OtherThing {
			otherThingIntegerValidator.lazy().validated(number);
		}
	}

[fredrik-forssen-cint]

But then the deserialization step will throw already when constructing the DTO which will be a lot more complex to handle. :)
I would actually prefer that the types used for deserialization does not have the constructor validation, so that they can be validated separately and then after validation is done get mapped to the actual domain types with validation in their constructors.

[making]

In such cases, shouldn't validation exist on the domain object side? With yavi, you can reuse domain-side validation for DTOs. https://yavi.ik.am/#validating-the-source-object-before-creating-the-target-object

Example: https://github.com/making/demo-spring-mvc-yavi/blob/main/src/main/java/com/example/yavi/web/UserForm.java

YAVI prefers to create an object after validation and provides various functions to achieve this.
https://yavi.ik.am/#validating-arguments

[fredrik-forssen-cint]

In such cases, shouldn't validation exist on the domain object side? With yavi, you can reuse domain-side validation for DTOs. https://yavi.ik.am/#validating-the-source-object-before-creating-the-target-object

Absolutely! However if you do that the the path in the constraint violations will relate to the object graph of the domain objects, not the names and the graph of the DTO. This of course makes the error messages less useful (or in some cases not useful at all).

And thus, we have circled back to the original question which was about how to manipulate the names returned. :)