How to prevent code to execute after firing of history token in gwt? - gwt

I am working on gwt2.3 application with gwtp framework.In this application I am have one login (index) page which is bind by the client module.
bindConstant().annotatedWith(DefaultPlace.class).to(NameTokens.login);
Now after successfull login a new name token name user page is fired.
History.newItem(NameTokens.userconsole,true);
Now I have my history handler like below:
public class NameTokenHandler implements ValueChangeHandler {
#Override
public void onValueChange(final ValueChangeEvent<String> event) {
System.out.println("Nothing to do");
}
}
And I added to History like below in entry point class:
History.addValueChangeHandler(new NameTokenHandler());
Now as I have overridden the onValueChange method & I have left it blank.
So when application loads first or any other name token fires it should invoke onValueChange first
and as there no code in this method nothing should be load.
But in application it is working fine. All the name tokens are firing successfully even after there is no code in onValueChange. I am not getting how to prevent the firing of history token?
Please help me out.
Thanks in advance.

So when application loads first or any other name token fires it should invoke onValueChange first and as there no code in this method nothing should be load.
If you are using gwtp History ValueChangeHandler will not prevent or enable navigation to a particualr part of your application. That is all handled with PlaceManager.

After some googling I came to know about place manager.
I am adding_ a change handler to History. All the change handlers that
have been added already are still there. In particular, the one in GWTP's
PlaceManagerImpl constructor.
If you really want to prevent some history events from being handled by
GWTP, I would suggest that, in your custom PlaceManager, you
override onValueChange(...), intercept the tokens you want to block, and
call the parent's onValueChange for the tokens you want GWTP to handle
normally.

Related

In wicket, how to make the page re-init when back button is hit

I'm using Wicket 6, and we have a situation where a user is hitting back and it's loading the page without initializing it from the page history. I want the page init to run so that data is read fresh and things are in the proper state. How can I make wicket do this?
I thought I was already doing this with a custom MountedMapper that someone had suggested long ago, but I have a breakpoint in the page constructor (the one that accepts PageParameters) and it's not running.
The custom MountedMapper:
if (requestHandler instanceof ListenerInterfaceRequestHandler || requestHandler instanceof BookmarkableListenerInterfaceRequestHandler) {
return null;
} else {
return super.mapHandler(requestHandler);
}
You could make your page stateless, so it is recreated on each access.
Or improved your page, so that it loads fresh data on each render:
either use appropriate models that automatically deliver up-to-date data or override #onConfigure() and update,

Wicket implement flash redirection

I would like to perform something like a flash redirection (not sure if it is really called flash redirection).
After a certain action like delete device, I am redirecting to the device list page.
Now, for the redirect URL... I am appending &sdr=true and it works.
The problem is... that parameter (&sdr=true) stays there even after just refreshing the page.
If I remember it correctly, when I do flash refresh... the parameter stays there but will disappear on refresh... or just good for one refresh only.
Below is my method for redirection:
public static void redirect(String redirectUrl) {
throw new RedirectToUrlException(redirectUrl);
}
now, how do I implement the flash redirection in wicket? I am using wicket 6 version.
Or... I would like the parameter &sdr=true be good only for 1 request. When the page is refreshed or reloaded... it should be gone.
Thanks :)
Sorry if this question is very easy, I am really new to wicket
May be there is another solution for your problem.
Wicket could be stateful, i.e. it can keep state between the pages navigation. So you can do:
setResponsePage(new SomePage(someState));
this way there is no need to pass anything in the url and SomePage's constructor can decide what to do with the passed state.
If you prefer to add request parameter in the url then you may use
PageParameters params = new PageParameters();
params.put("sdr", "true");
setResponsePage(SomePage.class, params);
In SomePage's constructor you will need to remove the sdr parameter from the passed PageParameters so that it is not rendered in all urls inside the page, e.g. in links, form action, etc.
But if you want the parameter to disappear in a page refresh/reload then you will need to make another redirect:
public SomePage(PageParameters params) {
super(params);
StringValue srdValue = params.get("srd");
if (!srdValue.isNull()) {
params.remove("srd");
// do something custom
throw new RestartResponseException(this);
// or throw new RestartResponseException(getPageClass(), params);
}
}

Grails: calling an action that uses withForm

I have a situation in which I need to reuse an action that has its functionality wrapped in a withForm closure.
Everything works well when submitting the form but when I try to reuse that action in another way I get redirect errors from my browser. Specifically, I need to redirect another action to it, possibly call it with chain, and I also want to call it from a hyperlink.
I'd really like to avoid creating a redundant action or having the invalidToken closure execute the same code. I've tried to find some more details about how withForm works and find out what happens if no token is passed to the closure but the Googles have let me down.
Is this possible? Am I trying to make it do something it can't?
More info:
I have a user edit controller action. It is wrapped with the withForm closure. There are three different cases in which I need to call this controller to render the user edit page:
An admin enters the user's id into an input and clicks the form
submit button (this form uses useToken). This needs to be secured
and protected from duplicate form submission.
An admin selects a user to edit from a list of employees by clicking
on the user's name (a hyperlink). Its possible I could turn this into a form submission with useToken and do some CSS styling to make it look like a link.
An admin creates a new user. When the user is successfully created
the create controller redirects (or uses chain) to the edit
controller. I can't find a work around for this, except to create a redundant controller.
If your code is used in more than one place a controller action isn't the best place to put it. I suggest you to move that piece of code to a service and call it from both actions.
Here is my solution. If anyone has some insight into other methods of solving this please contribute. I'm sure I'm not the only one that has had this problem.
The answer is due, in large part to #Sergio's response. It was far more simple than what I was thinking it would be. I created my edit action without withFormthen call it from another action that wraps the edit action in the withForm.
def editWT(Long uid, Long pid){
withForm{
edit(uid, pid)
}
}
def edit(Long uid, Long pid){
// Do lots of stuff to prep the data for rendering the view
}
This answer isn't innovative or ground-breaking but it works. I hope this helps someone else.

Zend AjaxContext, _redirect and hash navigation

first post in SO, even though I've been browsing it for years now to solve those mind-blowing and not so much coding problems.
What I want to do is:
* Use hash navigation (#!/).
* Use Zend controller actions, not php files.
* Load these actions through javascript/jQuery.
So far, I've got this working:
indexController, several Actions, each attached to AjaxContext via addActionContext(), I can call them though my javascript/jQuery file via "hashchange" plugin jQuery(window).hashchange(function(){ bla bla }). I can cycle through actions just fine.
But I want to redirect the user to a login page if he/she is not logged in, which brings me to my issue: How can I achieve that? The redirection is made to another controller (login controller, login action). I was trying something like $this->_redirect('/#!/login/login'); w/o any luck (yes, I've set up an AjaxContext in that controller's init). I keep getting a redirection error ("The page isn't redirecting properly"). If I just type in the address bar "/#!/login/login" I get everything display properly.
Anyway, thanks in advance!
Cheers
Now this starts to get complicated if you ever introduce other non-ajax contexts, but you could add the Ajax context to the Error Controller. Then have the error controller return JSON for the unauthenticated exception if the active context was AJAX (and keep the redirect if the default context was active). Your JS would then listen for that specific error provided by the JSON and manually bounce the user to the appropriate login URL.

GWT Fragment Identifier works in hosted mode and not in compiled mode (Tomcat)

I have this code below which works when running in hosted/debug mode however it does not work when deployed in Tomcat.
History.addValueChangeHandler(new ValueChangeHandler<String>() {
#Override
public void onValueChange(ValueChangeEvent<String> event) {
// call update model, and eventually app will show the appropriate view...
}
});
I code above responsibility is to catch the event when user type something like this in the browser:
http://http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997#user123
Works well in hosted mode, but when deployed in Tomcat and accessed via the browser:
http://127.0.0.1:8888/index.html#user123
it shows blank page.
EDIT: Unless gwt app is first loaded and typing FI works.
Please read this: What is need History.fireCurrentHistoryState() in GWT History?
When you load http://127.0.0.1:8888/index.html#user123 for the first time, you registered your history handler after the history event has already happened. If you reload the page then it will fire.
You need to call History.fireCurrentHistoryState() after you registered the history handler to "re-fire" the event.