NavigationConfirmationInterface question

[Laurent PETIT]

Hello,

I'm working successfully with mvp4g so far, I really appreciate what it brings to the table ! (we have been using it for more than 2 years).

I'm currently implementing correct history navigation.

The last thing that's left to do is prevent navigation via Hyperlinks if the current editor is dirty.

The problem is that if I use setNavigationConfirmation(new NavigationConfirmationInterface() { ... }), the history token will be placed in the browser's URL and history BEFORE the interface is called => so if I decide not to fire the event, then the URL nonetheless reflects the Hyperlink target's state.


Am I doing something totally wrong there, or do you confirm my experience / analysis?

If so, then I have a work-around in place, but it's kind of ugly, so I'd prefer, all-in-all, be proven wrong :-)


Cheers,

--
Laurent

[Frank Hossfeld]

Hi Laurent,

that sound as mvp4g does not handle the the navigation confirmation correct in case of using history. Will take a look and come back to you.

Frank 

[Laurent PETIT]

Rethinking a bit about it (and having implemented a working solution), here where I am:

- The navigation confirmation is implemented in the Place Service

- It is necessarily trigger *after* an history event when one clicks on an Hyperlink => it is then irremediably too late to ask for a confirmation, the History has been updated.

What I did is override the Hyperlink.onBrowserEvent() method. If a user confirmation is required (e.g. something is dirty), then the user is asked before calling super.onBrowserEvent().

Another alternative would be to not use Hyperlink, but use Anchor  => it is then possible to addClickHandler() and do this there.

But by doing so, we loose the good characteristic of Hyperlink with regards to the handling of browser-dependent things like Ctrl+Click (implemented in HyperlinkImpl.

--
You received this message because you are subscribed to the Google Groups "Mvp4g" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvp4g+un...@googlegroups.com.
To post to this group, send email to mv...@googlegroups.com.
Visit this group at http://groups.google.com/group/mvp4g.
For more options, visit https://groups.google.com/d/optout.

--

Laurent Petit

[Frank Hossfeld]

Hi Laurent,

I agree, triggering the confirmation after the History has been updated is in my opinion not correct. I will open an issue.

Frank

Am Sonntag, 28. September 2014 19:26:46 UTC+2 schrieb Laurent PETIT:

Rethinking a bit about it (and having implemented a working solution), here where I am:

- The navigation confirmation is implemented in the Place Service

- It is necessarily trigger *after* an history event when one clicks on an Hyperlink => it is then irremediably too late to ask for a confirmation, the History has been updated.

What I did is override the Hyperlink.onBrowserEvent() method. If a user confirmation is required (e.g. something is dirty), then the user is asked before calling super.onBrowserEvent().

Another alternative would be to not use Hyperlink, but use Anchor  => it is then possible to addClickHandler() and do this there.

But by doing so, we loose the good characteristic of Hyperlink with regards to the handling of browser-dependent things like Ctrl+Click (implemented in HyperlinkImpl.

Hi Laurent,

that sound as mvp4g does not handle the the navigation confirmation correct in case of using history. Will take a look and come back to you.

Frank 

Am Freitag, 26. September 2014 19:11:27 UTC+2 schrieb Laurent PETIT:

Hello,

I'm working successfully with mvp4g so far, I really appreciate what it brings to the table ! (we have been using it for more than 2 years).

I'm currently implementing correct history navigation.

The last thing that's left to do is prevent navigation via Hyperlinks if the current editor is dirty.

The problem is that if I use setNavigationConfirmation(new NavigationConfirmationInterface() { ... }), the history token will be placed in the browser's URL and history BEFORE the interface is called => so if I decide not to fire the event, then the URL nonetheless reflects the Hyperlink target's state.


Am I doing something totally wrong there, or do you confirm my experience / analysis?

If so, then I have a work-around in place, but it's kind of ugly, so I'd prefer, all-in-all, be proven wrong :-)


Cheers,

--
Laurent

--

--

Laurent Petit

[Laurent PETIT]

Yeah, I have banged my head against the walls one more day yesterday wrt this issue. 

There's little that can be done to prevent the history to change. 

In the case of hyperlinks, the workaround is to catch the click event. 

But for te back button, there's no escape: the previous state history will be popped, and then pop handlers will be triggered by the browser. 

Truth is: there's no possibility to veto a user-initiated history move: be it back, forward, or even random jump anywhere in the history. 

The application can only witness what just happened, and try to recover things afterward. 

#Fact 1 - the application can't veto/prevent History navigation

But things get worse ...

If we want to keep the history clean after an undesired history move: we need to disconnect the history events propagation while we revert the user change via History.forward() (if the user had clicked te back button but doesn't confirm the move when asked),  or History.back() if the user has clicked on the forward button). 

So you need to know the direction of the history move to revert it correctly. 

If you don't revert the history move, then the user will perceive that a history stack frame has been dropped.

#Fact 2: the HTML 5 History API doesn't inform of the direction of the move. Or more generally of the position in the History stack. 

Fortunately, it is possible to programmatically track the stack index, by using a combination of History.getState() and History.replaceState(). 

Unfortunately, GWT neither exposes History.replaceState() yet, nor the possibility to set a state object (it only exposes the history token). 

#Fact 3 - GWT hides important HTML5 API features. 

That's all for today :-)

--

You received this message because you are subscribed to the Google Groups "Mvp4g" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvp4g+un...@googlegroups.com.
To post to this group, send email to mv...@googlegroups.com.
Visit this group at http://groups.google.com/group/mvp4g.
For more options, visit https://groups.google.com/d/optout.

--

Laurent Petit

[Frank Hossfeld]

Hi Laurent,

sorry for the delay, but other projects needed my attention.

During the last week, I found some time to think about the problem and do some tests. 

As you already wrote, there is nothing you can do to avoid the update of the browser url.

The hyperlink navigation uses the place service to navigate. In case your project uses navigation confirmation, you will run into the problem you have, because: 

If you click the hyperlink, the url in the browser gets updated.

The updated url will be handle by a history converter which in the end fires an event.

The fired event will trigger the navigation confirmation. If the confirmation stops the event handling, the navigation does not happen but the url is already updated.

The only chance I see to avoid this behavior is to stop using hyperlink navigation and use a ClickHandler instead. The ClickHandler will handle the navigation click and will fire the event in case of a click event.

If you look here: 

http://mvp4g.blogspot.de/2011/07/hyperlink-navigation.html 

you can see how both implementations will work. 

Hope that helps.

Frank

Am Mittwoch, 1. Oktober 2014 09:13:10 UTC+2 schrieb Laurent PETIT:

Yeah, I have banged my head against the walls one more day yesterday wrt this issue. 

There's little that can be done to prevent the history to change. 

In the case of hyperlinks, the workaround is to catch the click event. 

But for te back button, there's no escape: the previous state history will be popped, and then pop handlers will be triggered by the browser. 

Truth is: there's no possibility to veto a user-initiated history move: be it back, forward, or even random jump anywhere in the history. 

The application can only witness what just happened, and try to recover things afterward. 

#Fact 1 - the application can't veto/prevent History navigation

But things get worse ...

If we want to keep the history clean after an undesired history move: we need to disconnect the history events propagation while we revert the user change via History.forward() (if the user had clicked te back button but doesn't confirm the move when asked),  or History.back() if the user has clicked on the forward button). 

So you need to know the direction of the history move to revert it correctly. 

If you don't revert the history move, then the user will perceive that a history stack frame has been dropped.

#Fact 2: the HTML 5 History API doesn't inform of the direction of the move. Or more generally of the position in the History stack. 

Fortunately, it is possible to programmatically track the stack index, by using a combination of History.getState() and History.replaceState(). 

Unfortunately, GWT neither exposes History.replaceState() yet, nor the possibility to set a state object (it only exposes the history token). 

#Fact 3 - GWT hides important HTML5 API features. 

That's all for today :-)

To unsubscribe from this group and stop receiving emails from it, send an email to mvp4g+unsubscribe@googlegroups.com.

To post to this group, send email to mv...@googlegroups.com.
Visit this group at http://groups.google.com/group/mvp4g.
For more options, visit https://groups.google.com/d/optout.

--

Laurent Petit