Validation and paging#

Validation comes in three levels#

Use only the lower levels, or only the top one. Either works.

Building a rule#

ValidationRule rule = new ValidationRule()
	.empty()
	.textLengthMax(100);

They run in the order you stacked them and stop at the first failure (one error per field).

Binding rules to columns#

ValidationRules rules = new ValidationRules()
	.put(Item.name, new ValidationRule().empty())
	.put(Item.age, new ValidationRule().integer(1, 120));

Data request = new Data();
request.putData(Item.name, "");
request.putData(Item.age, "999");

// エラーは最初の1件で止めず、全部集める（要件 F-V-03）
Data errors = rules.errors(null, request);

Data messages = ValidationMessages.toMessages(errors);

• Errors across fields are all collected (being told about them one at a time is the worst possible experience for the person retyping the form)
• A field that was not sent fails only the rules with empty() (required()) in them. Other rules do not look at it
• A rule with insertRequired() means "required on insert; on update, checked only when sent" (see "Required only on insert" below)
• When an array arrives for one column, every element is run through
• put(rule) (with no column) lets you write cross-field checks that belong to no single field

The raw shape of an error#

What errors(...) returns is not wording. It is which kind of check failed, and the settings it failed against.

{ "validation_type": Empty, "validation_setting": {}, "input": "" }

ValidationMessages.toMessages(errors) turns that into something a person can read: a map of field name to messages.

{ "title": ["入力してください"], "age": ["1 以上 120 以下の整数で入力してください"] }

Swapping the wording#

ValidationMessages.put(ValidationErrorType.Empty, (type, settings) -> "required");

ValidationRules rules = new ValidationRules()
	.put(Item.name, new ValidationRule().empty());

Data request = new Data();
request.putData(Item.name, "");

assertEquals(List.of("required"),
	ValidationMessages.toMessages(rules.errors(null, request)).get("name"));

Stop, or take the list#

Normally you write validate as a statement.

rules.validate(db, context.request().bodyAll());   // a 422 right here if it fails
db.insert(...);

If you do nothing else, the framework replies 422 with the body {"validation": {"field": ["message"]}} plus the input that was sent (the same shape as ValidationExecutor). It is an exception, so the error(...) hook does run (Error handling). ValidationException is a subclass of HttpException; errors() gives you the list.

When you want to look at the list and branch yourself, use errors(...). To run several sets together, use Validator.validate(db, data, rules...) / Validator.errors(db, data, rules...).

Required only on insert#

ValidationRules rules = new ValidationRules()
	.put(Item.name, new ValidationRule().insertRequired().empty())
	.insertRequestChecker(req -> req.getBoolean("is_insert"));

Data update = new Data();
update.put("is_insert", false);
assertTrue(rules.errors(null, update).isEmpty(), "更新なのに必須になっている");

Data insert = new Data();
insert.put("is_insert", true);
assertFalse(rules.errors(null, insert).isEmpty(), "登録なのに必須になっていない");

You hand the "is this an insert request?" decision to insertRequestChecker. The same decision reaches each validator as isInsertRequest.

Validating multiple rows#

ValidationRules rules = new ValidationRules()
	.put(Item.name, new ValidationRule().empty());

Data ok = new Data();
ok.putData(Item.name, "あ");

Data ng = new Data();
ng.putData(Item.name, "");

List<Data> errors = rules.errors(null, List.of(ok, ng, ok));

assertEquals(1, errors.size());
assertEquals(2, errors.getFirst().getInt("index"), "行番号が違う");

Only the rows with errors come back, and each one carries an index (1-based).

validate(db, list) throws ValidationException if even one row fails (the exception's errors() is {"rows": [...]}).

Applying it to a route#

Extend ValidationExecutor and write nothing but validate.

private class Failing extends ValidationExecutor {

	@Override
	protected void validate (WebContext context) {

		log.add("validate");
		addError("title", "入力してください");

	}

}

On the route, stack it first.

JimbleApp app = new JimbleApp() {
	{
		post("/items", context -> {
			context.addExecutor(new Failing());
			context.addExecutor(new UseCase());
		});
	}
};

When it fails, this is what you get.

You can also stack the result of ValidationRules directly.

addErrors(rules.errors(db, context.request().bodyAll()));

Paging#

Reading it from the request#

Paging paging = context.request().paging();

Write context.request().paging(20) to change the default used when no per arrives. There is one Paging per request, and the first one made is reused. Call paging() first and then paging(50) with a different count, and you get IllegalStateException. Pass the count on the first call.

Applying it to a SELECT#

Paging paging = new Paging();
paging.load(request("2", "10"), 0);

SelectListResponse response = DBUtil.getMainDB().selectListWithRowCount(select().paging(paging));

assertEquals(10, response.list().size(), "1ページ分だけ取れていない");
assertEquals(TOTAL, response.rowCount(), "総件数が LIMIT に影響されている");

assertEquals(TOTAL, paging.totalCount());
assertEquals(3, paging.maxPage(), "25 件を 10 件ずつなら 3 ページ");
assertEquals(11, paging.start());

selectListWithRowCount also issues a COUNT for the total. The COUNT statement copies only FROM / WHERE / GROUP BY / HAVING, so the SELECT list, ORDER BY and LIMIT have no effect on it.

What you can read#

It rides on the response#

The moment you call context.request().paging(), it is on the response. You do not repack it yourself.

{
  "rows": [ ... ],
  "paging": { "page": 2, "per": 10, "perAll": false,
              "maxPage": 3, "totalCount": 25, "start": 11, "count": 10 }
}

Templates see the same thing (${paging.page()}).

What to watch for#

An out-of-range page (?page=999) is not an error; it returns zero rows.