I'm currently working with lift and I recently faced a difficult with redirects.
When I try to show an error or notice with S.error, it redirects to the page which I was previously. And I couldn't find a work around for that. I assume it's a default behavior of lift and there should be a work around. Please post how to changed this behavior.
It's unlikely that S.error is causing the redirect.
I presume you're calling S.error while processing a form submission. If so, you need to call S.redirectTo or S.seeOther after your processing is complete to redirect the browser to a different page. If you don't Lift's default behaviour is to reload the form on which you have just clicked submit.
Related
I'm using scala 2.11.8 and Play Framework 2.3. I am submitting a form and managing the result through a controller. The controller returns a Redirect to a page flashing a certain message, either a success or an error message:
Redirect(routes.MyController.page).flashing("success" -> "All went well")
I then manage this message using javascript, so it can be seen in a modal:
#flash.get("success").map { message =>
<script type="text/javascript">
modalSuccess('#message');
</script>
}
All goes well, the modal is shown. Next I navigate to another page and use the Back arrow to go back and the modal is shown again. This is, of course, very weird for the user: he has just clicked back, it makes no sense that he sees a "All went well" message.
Previously, I passed these messages as parametres to the pages and returned a 200 OK:
Ok(views.html.page(message = "All went well"))
But the exact same thing happened because the request was sent again. I switched to Flash to solve this, but I can't seem to prevent it from showing when returning to the previous page.
Should I clear the Flash scope, or should it clear by itself, once the redirect is executed?
When you click back, by default the browser will serve the page out of its cache, it won't reissue the request, and that is what is happening here, it has nothing to do with Play.
There is no standard for how the browser back button behaves, in particular with regards to caching, so solving it isn't straight forward because all the browsers behave differently. This SO question/answer covers it fairly comprehensively:
How to control web page caching, across all browsers?
But be aware of the drawbacks, if you tell the browser it must never cache pages, you can end up giving users a poor experience, for example, if they are filling out a form, and they accidentally navigate away, and then click back so they can continue filling out the form, if you force the browser now to cache the page they will lose everything that they entered into the form.
Also, what if the reason they are clicking back is that they want to see the rendered model again? When users click back, they expect to see the page that they were just on, just as it was. If you change that, you're breaking their expectations. I wouldn't be happy if that happened to me - I hate it when I click back and I get a different page, you're probably going to upset your users if you do it.
I use the AjaxFallbackLink component for an Ajax link. When I mouse-over the link, the URL looks something like ./myPage?1-1.ILinkListener-xxx. And when I actually click the link, however, the Ajax request looks something like: ./myPage?1-1.IBehaviorListener-xxx.
It seems that Wicket JavaScript has somehow changed the URL from ILinkListener to IBehaviorListener. Wonder if it is so, and why is that?
Sometimes in certain circumstances ILinkListener in the URL is not changed to IBehaviorListener when the request is sent out by the browser, which causes NullPointerException as parameter AjaxRequestTarget target in the callback function is null. I haven't been able to reproduce this. Just wonder what browser settings could cause this to happen. Thanks a lot.
Both of those URLs are correct.
The first static link address './myPage?1-1.ILinkListener-xxx.' is a generic link address for a link in case it invokes a URL and process the link.
The second AJAX link address './myPage?1-1.IBehaviorListener-xxx' is a generic JavaScript/AJAX behavior. In case when JavaScript is working, the JavaScript is attached as an onclick event (see jQuery click() function at https://api.jquery.com/click/) and it processes the link, then it shouldn't continue to process the URL from HREF attribute.
So far you would expect to request only one of those URLs when the link is clicked. But in case of AjaxFallbackLink when there is no AJAX then onClick(AjaxRequestTarget) is invoked as onClick(null), it causes NPE if you rely on existing AjaxRequestTarget object, but there is no guarantee for that.
The last part of your question is not clear when it is not possible to reproduce. But Wicket uses jQuery, if you add jQuery library into the HTML, there is a possible conflict of versions.
There are some more detail on a similar issue at http://apache-wicket.1842946.n4.nabble.com/AjaxFallbackLink-s-onClick-with-null-AjaxRequestTarget-migrating-1-4-to-6-td4652143.html
I'm pretty new to Play Framework.
My problem is that when a user clicks on the register link, he will instantly see validation errors.
The problem is that the method that serves the form also validates the form. So when the user clicks on the register link, gets to the validation without any input and then gets validation errors.
One solution would be to have an extra method to only serve the register form. But this would require an extra form and an extra route.
Another solution would be to disable validation on empty forms.
Is this possible? If not is there an other way?
You are on the way to a good solution. Make a second method.
GET /register controllers.RegistrationController.showRegistration()
POST /register controllers.RegistrationController.register()
The first is to display the registration page with the form, the latter to handle the form submit.
A method should stick to do one thing: either to show a registration page or to handle a post. Generally it's not a good idea to write a single method with a lots of if-then-else flow control statements.
Play framework also supports REST principles: in a simplified way GET is to retrieve a resource (=an empty registration page here), POST is to submit data(=do the registration).
Have a good look at Play framework's examples, I think the computer-database is very simple and a good starting point for you.
I administer a site, hosted on Yahoo! hosting, which has recently shown a strange behavior: when you visit in IE8, the page loads and is rendered normally, then as soon as it finishes rendering, the browser switches to show its local/internal 404 page. The address bar still shows the site URL.
When I view the site in (as far as I can tell) the same state on my local Apache server, it doesn't do this. This leads me to suspect it may have something to do with server configuration and response headers, but I don't know what that might be.
Is anyone familiar with this behavior?
I experienced this behavior when using a .htc hack to provide artificial CSS border-radius support.
I'm not sure what is causing that issue specifically, but you could use a packet capture utility like Wireshark or Fiddler2 to investigate the issue further. Otherwise, it would be helpful if you were to post a link to the site.
Your page contains JavaScript code which modifies the DOM while the page is still loading.
See other SO questions, such as here and here.
Solution: place your DOM manipulation code into < body onload> or jquery.ready() to execute after page loading is complete.
I have a form that submit a shopping cart to Google Checkout. The form works great on it's own, but when I put it inside of Joomla (using a content-type of wrapper), Google Checkout throws a 302, and the form page is loaded again.
As I was writing this, I then decided to see what happens from the static form, outside of Joomla. It took gets a 302, but Google Checkout loads.
If I go directly to the request url listed in the resource inspector (using chrome for this), I get an error:
Oops!
We were unable to process your request.
That happens on both the Joomla wrapped form and the stand alone.
However, both forms receive response headers, with a Location url that goes to Google Checkout, and in fact loads the proper data.
Any ideas how to get this working inside of Joomla? Or what I might be doing wrong?
I don't know this stuff well enough to explain myself too well, so if you have a clarifying question, I'd be more than happy to provide as much info as possible.
The issue was in fact that the form was trying to redirect the entire page from inside an i-frame. Brought the form out into a component and it works fine.