попробовала detect плагин, 1. если он и содержит в себе ktlint - не удобно что не появилось gradle таски ktlintFormat, которой очень удобно пользоваться при изменеии многих классов - она форматирует автоматически. В detect не нашла ничего подобного.
Detect plugin has not this task instead of Ktlint pluginнастройка detect
2.отступы разные detect спокойно отработал как success, т.е. по форматированию он не так строг как ktlint (хоть и устновлено свойство detect allRules = true, тоже не понравилось).
3.напишу ещё позже, что будет попадаться в сравнении - первое впечатление не очень.
"In Spring, we use JSR-303's @Valid annotation for method level validation. Moreover, we also use it to mark a member attribute for validation. However, this annotation doesn't support group validation.
Groups help to limit the constraints applied during validation. One particular use case is UI wizards. Here, in the first step, we may have a certain sub-group of fields. In the subsequent step, there may be another group belonging to the same bean. Hence we need to apply constraints on these limited fields in each step, but @Valid doesn't support this.
In this case, for group-level, we have to use Spring's @Validated, which is a variant of this JSR-303's @Valid. This is used at the method-level. And for marking member attributes, we continue to use the @Valid annotation."
Да, Вы правы, можно сообщение и сразу непосредственно вставить в поле message, но в таком случае сообщения будут раскиданы по коду. Мы решили сделать централизованное место для сообщений ошибок, потому записываем в файл. Тут вопрос может не очень категоричный и можно делать по разному - кому как удобнее.
В случае с полями с nonnull типами (это не касается Int/Long), да, при вызове end-point со значением null исполнение свалится с Exception, но таким: HttpMessageNotReadableException
org.springframework.http.converter.: JSON parse error: Cannot construct instance of `com.epam.brn.dto.StudyHistoryDto`, problem: Parameter specified as non-null is null
Нам показалось разумнее сделать всю валидацию с помощью Spring однообразно для всех типов. Потому мы реализовали вышеописанный вариант.
попробовала detect плагин,
1. если он и содержит в себе ktlint - не удобно что не появилось gradle таски ktlintFormat, которой очень удобно пользоваться при изменеии многих классов - она форматирует автоматически. В detect не нашла ничего подобного.
2.отступы разные detect спокойно отработал как success, т.е. по форматированию он не так строг как ktlint (хоть и устновлено свойство detect allRules = true, тоже не понравилось).
3.напишу ещё позже, что будет попадаться в сравнении - первое впечатление не очень.
Так и описано было изначально не "над контроллером", а перед DTO, с примером ниже.
Разница @Validatedи @Validподробнее описана здесь.
"In Spring, we use JSR-303's @Valid annotation for method level validation. Moreover, we also use it to mark a member attribute for validation. However, this annotation doesn't support group validation.
Groups help to limit the constraints applied during validation. One particular use case is UI wizards. Here, in the first step, we may have a certain sub-group of fields. In the subsequent step, there may be another group belonging to the same bean. Hence we need to apply constraints on these limited fields in each step, but @Valid doesn't support this.
In this case, for group-level, we have to use Spring's @Validated, which is a variant of this JSR-303's @Valid. This is used at the method-level. And for marking member attributes, we continue to use the @Valid annotation."
Да, Вы правы, можно сообщение и сразу непосредственно вставить в поле message, но в таком случае сообщения будут раскиданы по коду. Мы решили сделать централизованное место для сообщений ошибок, потому записываем в файл. Тут вопрос может не очень категоричный и можно делать по разному - кому как удобнее.
Да.
В случае с полями с nonnull типами (это не касается Int/Long), да, при вызове end-point со значением null исполнение свалится с Exception, но таким: HttpMessageNotReadableException
Нам показалось разумнее сделать всю валидацию с помощью Spring однообразно для всех типов. Потому мы реализовали вышеописанный вариант.
Сейчас у нас нет диагностического блока для проверки слуха, но мы думаем об его разработке, добавлении в будущем, чтобы пользователь мог раз в квартал допустим проверять свою динамику, прогресс.
И рассматриваем сейчас такие решения:
1. www.phonak.com/ru/ru/proverka-sluha-onlain.html
2. www.researchgate.net/project/Smartphone-based-Audiometry-A-Preliminary-Validation-Hearing-Screening-App
Матричные упражнения у нас уже реализованы. Их цель как и остальных серий упражнений — развитие понимание речи, не тестирование.
спасибо за ссылку, но дальше идеи, как я поняла, они не ушли. или есть реализация их теста где-то? Было бы интересно тоже посмотреть.