Question

I am soooo confused by the playframework flash stuff….high level makes sense, “put stuff in flash on the http POST to be able to retreive on the http GET after the redirect”. and I am guessing you “could” put stuff in GET request to be retrieved on next GET request but very very ick, ugh, yuck on that one since flash is shared between tabs ;).

I have the following and it requires params.flash and Validation.keep or my page stops working….(good so far)….

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

of course later on, I have this and adding those in BREAKS the functionality in this case….

    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);
    }

so was registerCompanyPage doing a redirect EVEN though the code in it calls render???? (I did not post that code in here) and when I change render in my second method to redirect(), well, then I just get controller can’t be found at all and it completely stops working.

I look at all the Validation in the samples in playframework and they all do a render with no Validation.keep nor params.flash, so what is going on here? At one point, I thought I removed Validation.keep and something else broke, but can’t seem to reproduce it right now.

Anyone fully understand what is going on here?

thanks,
Dean

Answer 1

Any call to a public static method invokes a redirect. (check the url in the browser to confirm if you like…i.e its not the same as the action you called as part of the POST).

So, in your first example, you need to use flash, so that the errors are not lost following the redirect back to the original page.

Your second example is rendering directly within the action. So, using flash, you are storing stuff up ready for the next request, which obviously is bad, as you may not have any errors.

The examples you see online will differ for a couple of reasons. The original view was to use flash, and force a redirect back to the original page. This kept the url and the actual current page you are seeing in sync. However, as flash is a cookie, you have a limitation of storing the parameters, and error messages in a medium that can only contain 4Kb. Therefore people generally use your second method. Its not as RESTfully clean, but it does prevent the need for cookies, as there is no redirect.