This is probably a silly question, but I have tried looking how to get there through Window, Root, and Navigator and just can’t seem to figure it out.
I am using Vaadin Beta 9 and am trying to execute an external redirect which will allow a return into the same session (in this case it is a PayPal transition). I have tried Navigator, VaadinService and altering the response code, I can’t seem to figure out the Root to see if that will get me what I need.
Any assistance would be great as my forum searches have come up for naught.
After a bit of playing around, I was able to implement the same functionality using a Link and some changes to the View. I would still like to know what the recommended approach is to doing a true external redirection that will allow for better "flow’ of this.
Well, I don’t have a complete answer. I still need away to get back into the application. The problem is the following:
PayPal uses a return and cancel URL supplied to it. On the return to the application, PayPal appends URL parameters indicating state information and successful/failure of the call.
Thus using fragment URI’s as the return/cancel to PayPal fails with an unable (fragment looks like ?paypal1=xxxx&paypal2=cxvcxv)
I have tried the following:
1 ) Provide PayPal the following URL: http:///?pid=
2) Add a ViewChangeListener to the application UI
3) in the beforeViewChange, see if the param pid exists. If it does, rip it out and set the return to false.
4) in the afterViewChange set the getPage location to fragment.
(note: I have tried various combinations of 3 and 4 where the beforeViewChange returns true, false, the page location is set in the before or after).
Thoughts? Suggestions?
In summary the questions is: I have an external app which is going to return to the Vaadin app. The external app is going to send some URL parameters back and needs to return to a specific page to be processed. How can it do this?
Do you mean PayPal just blindly
appends query parameters to the URI instead of inserting them into the proper position? Sounds… interesting.
I think you should be able to have a hashless PayPal return URI and in your UI init() check if the requested location matches that URI, and if so, Page.setLocation() to the proper hashbang URI. It suffices to do this in init() because when you synchronously load a page, a new UI is always created and init() called.
Another way to work around this is to write a custom UriFragmentManager that overrides either getState() or getFragment() so that the ?foobar appended by PayPal is ignored when parsing the view name. Then you can use Page.getUriFragment() to parse the PayPal parameters.
That’s exactly what PayPal is doing. I submitted fragmented URL’s for the return/cancel and they append the params to the end of the fragment. I finally did get it working doing something similar. I added the functionality to the ViewChangeListener since I have PreserveOnRefresh set (correct me if I am wrong, but that only fires the UI init once so that I can’t do the URI checking in the init of the UI).
Would it be possible to add a check to the framework’s UriFragmentManager to verify that there are no URL params after the fragment and merge them with params before the request? While I realize that this isn’t the way URI’s aren’t supposed to be built, it does provide a safety mechanism incase an external site/service is not handling them correctly.
Oh, right. You could then also write a separate non-PreserveOnRefresh UI class assigned to the return URI you’d like to use, redirecting to your main UI.
It might be helpful if UIs had a “reinit” method that’s called whenever a PreserveOnRefresh UI is reloaded – it would have a couple of other use cases as well.
Checking the fragment for potential query parameters by default does not seem something the framework should do – it is, after all, a corner case that’s quite easily worked around. Besides, what if the user wants to have them there?
Actually, yet another idea that I didn’t think of until now is simply making sure that the fragment in your return URI has a trailing slash, like http://foo.bar/#!baz/ . Then the view name should be parsed correctly and the parameters passed to the view as a string.