The search is over

[tonsky]

Наконец нащупал ту самую истину, которую я все пытался сформулировать тут и тут. Про веб-программирование, фреймоврки и отчего Wicket - такое беспросветное говно. Тут не противоречие stateless природы веба и stateful фреймворков, как мне казалось. Элементарно, писать программу, где у объектов есть состояние, у страницы есть состояние и т.д., в сто раз сложнее, чем программу, состоящую из набора функций http-запрос → http-ответ без сайд-эффектов. Это как все пишут про функциональные языки, убираем внешнее состояние, и, ну вы знаете, все становится легко, прозрачно и надежно. Парадигма запрос→результат сама провоцирует на написание лучшего кода, который отлаживать проще, переиспользовать проще, понимать проще, тестировать проще. Вот и всё откровение. Тот, кто пишет, что Wicket или еще какой-нибудь stateful-фреймворк облегчит вам жизнь, нагло врет.

Кому интересно, понял я это сегодня, глядя на феерическую страницу, со сложностью которой разработчики не совладали, и начали копировать хранящиеся в странице объекты, чтобы если в одном месте объект кто-то меняет, в другом ничего не навернулось. (натурально, BeanUtils.copyProperties, «Нужен для предотвращения сохранения объекта с недопустимыми значениями. onBeforeSave у AbstractEditPanel вызывается после sumbit формы, поэтому в родительской панели объект также может быть изменён.») Ну где за таким уследишь? Вот и сидим в состоянии «давайте еще поднапряжемся, чтобы не развалилось» вместо собственно разработки функционала.