playframework для вспышки или не для вспышки

Question

Я так ошеломлен флеш-файлом playframework .... на высоком уровне имеет смысл ", поместите вещи в flash на http POST, чтобы иметь возможность вернуться на http GET после перенаправления" , и я угадываю, что вы «могли» помещать материал в запрос GET для получения следующего запроса GET, но очень сильно ick, ugh, yuck на нем, так как Flash делится между вкладками;).

У меня есть следующие, и это требует params.flash и Validation.keep или моя страница перестает работать .... (хорошо до сих пор) ....

if(Validation.hasErrors()) { 
     params.flash(); // add http parameters to the flash scope 
     Validation.keep(); // keep the errors for the next request(after redirect) 
     registerCompanyPage(); 
    } 

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

if(Validation.hasErrors() || !license) { 
     Validation.keep(); //BREAKS functionality!!!! as errors NEVER go away now after getting them just once 
     params.flash(); //BREAKS functionality as stuff NEVER goes away now 
     log.info("errors="+Validation.errors()); 
     flash.error("Errors in form"); 

     log.info("company url="+company.getCompanyUrl()); 
     render("@registerStep2Page", user, company, license); 
    } 

так было registerCompanyPage делать редирект несмотря на то, что код в нем вызовов рендеринга ???? (Я не размещал этот код здесь), и когда я изменяю рендеринг в своем втором методе на redirect(), ну, тогда я просто получаю, что контроллер не может быть найден вообще, и он полностью перестает работать.

Я рассматриваю все валидацию в образцах в playframework, и все они выполняют рендеринг без проверки Validation.keep и params.flash, так что происходит здесь? В какой-то момент я подумал, что я удалил Validation.keep и что-то еще сломал, но, похоже, не может воспроизвести его прямо сейчас.

Кто-нибудь полностью понимает, что здесь происходит?

спасибо, Дин

Answer 1

Любой вызов общественного статический метод вызывает редирект. (проверьте URL-адрес в браузере, чтобы подтвердить, хотите ли вы ... т.е. это не то же самое, что действие, которое вы назвали частью POST).

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

Ваш второй пример - это визуализация непосредственно внутри действия. Таким образом, используя flash, вы сохраняете готовый материал для следующего запроса, что, очевидно, плохо, поскольку у вас могут не быть никаких ошибок.

Примеры, которые вы видите в Интернете, будут отличаться по нескольким причинам. Первоначальное представление состояло в том, чтобы использовать flash и принудительно перенаправить на исходную страницу. Это позволило сохранить URL-адрес и фактическую текущую страницу, которую вы видите в синхронизации. Однако, поскольку флэш-файл является файлом cookie, у вас есть ограничение на сохранение параметров и сообщений об ошибках на носителе, который может содержать только 4 КБ. Поэтому люди обычно используют ваш второй метод. Это не так, как RESTfully clean, но это предотвращает необходимость использования файлов cookie, так как нет перенаправления.