В каком месте оно обычное? Я сам юзаю этот механизм для вытаскивания JPA модели и это очень хреново работает

ты напрямую JPA кидаешь на шаблон?

нет ты не понял о чем в видосе речь, в метод initCreationForm там попадает объект Owner который перед этим вытаскивается из БД с помощью метода findOwner, вот про это я говорил

а по поводу шаблона я сейчас юзаю DTO везде иначе можно словить миллион всякой херни от JPA/Hibernate

ага, понял тебя

он не считает аннотации дикостью, глянь его либу jcabi

http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html

да и че, там же все нормально описано в чем их минусы

вот кстати в этом видосе отлично показано какой пиздец вспринге

да нет там никакого пиздеца

есть

я уверен ты даже не в курсе

что там может стрельнуть

да и вообще мало кто в курсе как там @ModelAttribute работает внутри

не в курсе чего? того как они процессятся?

да, когда отрабатывает @ModelAttribute?

например

до входа в метод обработки запроса или после

?

после выхода из метода я имею ввиду

конкретно его не юзаю, но неужели этого нет в доках или сложно посмотреть в исходниках?

ну вообще и на вход и на выход он вроде как работает. в зависимости от того куда воткнул его

а ты сорцы спринга читал?

если на метод - тогда на выход

а если я на метод класса повесил его

просто на левый

те что мне нужны были - да, читал

ну это не самое простое дело разобраться что они там делают, потому что кода куча, прочитав его один раз через месяц все забываешь что там написано

и по поводу @ModelAttribute он отрабатывает и на входе и на выходе все верно, и вот в этом видео на входе в метод Owner вытаскивается из репозитория

бинлится на параметр метода

просто на левый

его разве что-то обработает? он же только в контексте контроллера работает

конечно работает

если ты вешаешь @ModelAttribute на метод в классе то он всегда отрабатывает на входе и выходе из обработчиков запросов

большиство людей думают что @ModelAttribute просто кладет данные в модель шаблонизатора

но фактически он еще дохрена всего умеет делать

что в доках плохо описано

30 секунд потребовалось чтобы найти https://github.com/spring-projects/spring-framework/blob/1ee0626c94e6862fc21c99257e53433ee7ce4d36/spring-web/src/main/java/org/springframework/web/method/annotation/ModelAttributeMethodProcessor.java

я со спрингом мало работаю, а то с чем я работаю знаю довольно хорошо в плане исходников и особенностей работы. так что я думаю для тех кто работает каждый день со спрингом на протяжении 10 лет нет никаких проблем с этим

если б не было в джаве аннотаций знаешь что было б?

писали б в docblock их и разбирали рефлекшенами, как это сейчас делается на пхп

и это куда неудобнее чем нативные аннотации

а не проще явно обернуть в функцию?

собсно как и сделано в питоне с аннтотациями

что именно?

можно и мапу просто вернуть, чтобы очевидно было)

@f def g(): ... == def g(): ... ; g = f(g)

30 секунд потребовалось чтобы найти https://github.com/spring-projects/spring-framework/blob/1ee0626c94e6862fc21c99257e53433ee7ce4d36/spring-web/src/main/java/org/springframework/web/method/annotation/ModelAttributeMethodProcessor.java

это конечно круто что ты нашел код, а теперь попробуй вникнуть что он там делает

@f def g(): ... == def g(): ... ; g = f(g)

просто, красиво, понятно и искать легко а с джавовскими аннотациями быстрее ноут разбить со злости, чем вьехать в магию

нет, бывают простые аннотации сорцы которых даже читать не стоит потому что и так ясно что они делают, но в Spring другой случай, там аннотации ради аннотаций а не ради удобства

@ModelAttribute которые по идее должен биндить данные в модель шаблона на самом деле умеет еще и биндить параметры в метод

@RequestMapping который нельзя оверрайднуть или расширить в наследнике

3 разных аннотации для инжекта

2 аннотации для транзакций

ты еще вспомни аннотации для DI в 2х вариантах

в 3х

@Autowired, @Inject, @Resource

@Repository,@Component,@Service

@Autowired, @Inject, @Resource

надо написать этим людям

@Autowired, @Inject, @Resource

@Named, @Qualifier, @Singleton, @Controller ...

@RestController

кстати те что ты перечислил вполне нормальные

к ним нет претензий

а искать из идеи че делает эта аннотация вообще без проблем

потыкал везде брейкпоинты, посмотрел и все. как по мне нет ничего сложного

другое дело если б там магические методы были, которые непонятно где и как процессятся

через eval

ERROR: S client not available

или какие-то подключаемые скрипты

ок, почему нельзя @RequestMapping переопределить в классе наследнике?

а можно подробнее, а то интересно, а вопрос я ваш не понял)

вообще нельзя переопределить?

есть интерфейс в определенными методами, например put/get/post/delete я вешаю на каждый из них @RequestMapping с URL "/put", "/get" и т.д. называю интерфейс Crud и делаю несколько наследников, например AccountCrud, TableCrud и т.д., в них я вешаю одну аннотацию @RequestMapping уровня класса с каким нибудь префиксом, например @RequestMapping("/accounts"), и вуаля у меня 4 URL /accounts/put, /accounts/get и т.д.

вообще нельзя переопределить?

можно создать базовый класс но не вешать аннотации @RequestMapping, затем унаследоваться от класса и там уже на нужные методы повесить аннотации @RequestMapping

а если переопределить метод, но не трогать аннотации?

тогда просто будет URL который был объявлен в базовом классе, т.е. просто /get

без /accounts вначале

а что по этому поводу разрабы спринга говорят?

говорят пока не будем делать

когда то я находил баг у них открытый уже несколько лет но сейчас искать в лом

может ошибаюсь

на стековерфлоу есть вопросы от людей

есть даже либа которую пилили чтобы решить косвенно эту проблему вроде https://github.com/resthub/springmvc-router

сделать маппинг URL в стиле djano

а свою анотацию запилить, которая будет добавлять этот префикс)

и на наследника вешать ее

этот код придется поддерживать, плюс придут новые разрабы которые будут вникать, мы выбрали путь не указывать @RequestMapping в базовом классе, а указывать в наследниках, немного больше кода получается но суть таже

нашел у нас такое, сделано так же)

этот код придется поддерживать, плюс придут новые разрабы которые будут вникать, мы выбрали путь не указывать @RequestMapping в базовом классе, а указывать в наследниках, немного больше кода получается но суть таже

а если на Jersey перекатиться?

у него и с маппингом получше

ну в новых проектах я пытаюсь не юзать Spring(ну кроме нормальных по моему мнению либ типо Spring Security или IOC или AOP)

или Spring JDBc

IoC/AOP/Data самое годное

+ бут

многозначительно

а для апи можно и jersey взять

Data не, бут хз, его юзаем есть плюсы есть минусы, для быстрого старта ок, потом нужно допиливать

проперти там повыставлять, где то их авто конфигурации отключить

в буте только напрягает что нужно отключать модули вручную которые не нужны

согласен