I have an activity with a mayStop() method. I am having two issues with it that pertain to a hyperlink on the page.
The first issue is that if I hit refresh or the window's X I get a dialog box that wraps my mayStop() text with "Are you sure you want to navigate away from this page?" and "Press OK to continue, or Cancel to stay on the current page." That is fine.
When I hit the hyperlink, I only see my mayStop() text without the wrapping text. Why is that?
The second issue is that if I hit Cancel in response to the hyperlink click, hitting the link again results in not getting the mayStop() challenge at all. It is as if I am not hitting the hyperlink.
Has anyone run into these issues?
Any thoughts?
Thanks,
Doug
The difference in "behavior" is that the first dialog box is the one from the browser when you try to prevent the user from navigating away, while the other is PlaceController calling Window.confirm(). Each browser uses a different dialog box for the first case, so there's no way to mimic it for everyone, and it's probably not a good thing either (navigating away from the app vs. navigating within the app).
As for your second issue, the events are generated by the browser "history" changing; if you prevent navigating away (from the Place), the URL stays the same (there's noway to know what to do to "rollback" the change: History.back(), History.next(), History.newItem() but then you destroy the existing "next" history ?), so when you click again on the link, you don't make the URL change, and no event is fired.
It's expected that you use PlaceController.goTo to navigate when you use places, not Hyperlink or History.
Related
I can go to my page PgMain by a lot of way (end of action, logout, button go to menu, button back, system back button, etc.). I want clear my routing every time, where I open PgMain page. How to do it inside PgMain class, for example inside build method? As I said previously, I have a lot of ways to go to PgMain, and not at every case I can use Get.offAll() method
Use
Get.offAll(PgMain()); Get.off(PgMain());
whenever you navigate to PgMain page.
I have a Browsing carousel in my Action that opens a new page. From that page, I want to give the user an option to either continue on the website or to close the website and go back to the Action.
If they select the option to go back - how can I send them back to the Action?
You can't "go back" to the Action in the same way as if you clicked on a back button in the browser.
However, you can create a link on the page that you're showing the user that will re-start the Action or re-start it with a particular "deep linked" Intent. If you maintain the state of the user when they leave your Action, you can restore that state when they return, but that is up to you to manage.
To create a link to start the Action go to your Action console, select the "Actions" navigation on the left, and then the right arrow for the Intent that you want to be able to link to.
Towards the bottom of the screen that comes up, you may need to click on the "Links" header to expand that section, and then turn the switch on for "Would you like to enable a URL for this Action?"
The section will expand to prompt you for a Link Title (which is required, but not really used for anything) and will show you an HTML code snippet with the link. You are allowed to change this link however you want, but you must use a link - you can't do something clever like try to redirect to that page.
For the time being, this is a Material-UI question.
I have a situation where the tab key ceases to move the text cursor between TextFields. At the moment, I have no idea where in my code this is happening, and I am hoping someone can point me in the right direction so I can start looking.
Here’s the setup:
A mouse click causes a Dialog to be displayed. The Dialog has
several TextFields as well as 2 FlatButtons, “cancel & “submit”
At this state, tabbing between fields works as expected.
If I hit the “cancel” button, an event is fired which updates state (including the display of the Dialog) and the Dialog is closed. I can repeat the process from the top with no issues.
If I hit the “submit” button, an event is fired which does some async stuff (using rxjs epics).
On success, the epic fires an event which updates the state (including the display of the Dialog)
If I now try to repeat the process from the top, the tab key does not respond.
I am in the process of migrating to v1, and checked some of the v0.* components – they have the same problem – I don’t recall that being an issue before… Possible conflict between the two versions of the library?
Figured it out. Yes, there is a conflict between the v0.20 and v1.0 of the Dialog component. At least when you have one opening on top of another. Having changed all Dialogs to v1.0, the problem disappeared.
By the way, its not that the tab key wasn't responding - it was responding in the lower Dialog component and not in the top (latest to be created) one. This problem disappeared once the same version was used for both.
I'm trying to understand how Facebook implements the chat sidebar. It seems to stay there even as I change pages. For example, if I select some text inside the sidebar, then click to go to another Facebook page, the text remains selected. It's as if it was a separate frame, but when I look at the code, it's not.
All requests are made trough AJAX calls. Only "content" container is replaced when needed.
You don't actually "go" to another page. Just the "content" div gets updated.
There is a container DOM element called "fb_content", its content is replaced through straight-forward AJAX or more technically XMLHttpRequest. (Although when for example you enter an app, the entire page is refreshed.) To update the address bar they use the JavaScript History API.
In addition to what Zeno and lericson said (fb_content gets updated via ajax), the address bar also gets updated while maintaining the history (if you press back/forward).
When to use HyperLink and when to use Anchor?
When using HyperLink how to handle clicks?
com.google.gwt.user.client.ui.Hyperlink.addClickHandler(ClickHandler) is deprecated
com.google.gwt.user.client.ui.Hyperlink.addClickListener(ClickListener) is deprecated as well.
Doc suggests to use Anchor#addClickHandler, but how to use Anchor#addClickHandler when using HyperLink
Does it mean that if I need to handle click I should always use Anchor and never use HyperLink?
Great question, because it is so simple, and yet opens up what might be a whole new area for a lot of GWT programmers. I've up-voted the question just because it can be a great lead-in for people exploring what GWT can do.
Anchor is a widget for storing and displaying a hyperlink -- essentially the <a> tag. Really not much more exciting than that. If you want your page to link to some external site, use anchor.
Links are also used for internal navigation. Let's say I have a GWT app that requires the user to login, so on my first panel I put a login button. When the user clicks it, I would display a new panel with widgets to collect the user's information, code to validate it, and then if validated successfully, reconstruct that first panel the user was on.
Buttons are nice, but this is a browser, and I want my user's experience to be more like a web page, not a desktop app, so I want to use links instead of buttons. Hyperlink does that. The documentation for hyperlink describes it well:
A widget that serves as an "internal" hyperlink. That is, it is a link
to another state of the running application. When clicked, it will
create a new history frame using History.newItem(java.lang.String),
but without reloading the page.
Being a true hyperlink, it is also possible for the user to
"right-click, open link in new window", which will cause the
application to be loaded in a new window at the state specified by the
hyperlink.
That second sentence should help clear it up. The hyperlink is not changing the page in a URL sense (the way anchor does), though the URL will reflect the state of the program by displaying the "token" associated with the hyperlink appended to the base URL after a slash. You define the token. It would be something descriptive like "login" or "help" or "about". But this isn't a new page. There is no additional HTML file you've had to construct to display a help page, for example. It is the state of the current GWT app that is changing. Even if you "open in a new window" you are just running the same app in a particular state.
It looks like a link, but it is really a widget that manipulates the history frame, which in turn allows you to move the state of your GWT application. You don't write a click handler for the hyperlink widget, but a value change handler for the history stack. When you see that the "help" token has been put on the history stack, your handler will execute GWT code to attach to the RootPanel a FlowPanel with embedded HTML text with your help information. This is perceived by the user as a "new page", which is what he expects when he clicks on a hyperlink. The URL will be something.html/help. Now pretend he returns to this URL via the back button, not your hyperlink. No problem. You don't care about the hyperlink click. You only care that, somehow, the history stack changes. Your value change handler fires again, and does the same thing as before to display the help panel. The user still enjoys the experience of navigating through web pages, even though you and I know that there is only one web page and that you are attaching and detaching panels to the RootPanel (or whatever scheme you are using to display your GWT panels).
And this leads to a bonus topic.
This bonus is a bit more complicated, but ironically, it could help better understand hyperlinks. I say more complicated, but really, it helps solidify this notion that a GWT application is made up of a series of states, and that the web page on the screen is just the user's perception of those state changes. And that is Activities and Places. Activities and Places abstracts away this history frame manipulation, handling it in the background once you've set up a mapper with a GWT-provided class designed for this purpose, allowing you to break down your app into a series of activities, and as the user interacts through these activities he is put into different places, and each place has a view. Moreover, the user can move from place to place using browser controls like the address bar, bookmarks, history, and the backward/forward buttons, giving the user a real web-like experience. If you really want to get a grip on the conceptual difference between hyperlinks and anchors, you should try to learn this GWT topic. It can really make you change the way you see your apps, and for the better.
Hyperlink (or InlineHyperlink) is basically no more than a kind of Anchor with a ClickHandler that calls History.newItem and preventDefault() the event (so that the link is not actually followed).
Actually, Hyperlink won't do that if it thinks (and yes, it's only a guess) you right-clicked or middle-clicked (or ctrl-clicked) on the link (depending on the browser), to open the link in a new window or tab.
If you need any other behavior, then don't use Hyperlink and use Anchor instead. And if you want to add some behavior to an Hyperlink, then use an Anchor and mimic what the Hyperlink does. And you can reuse the HyperlinkImpl to have the right-click/ctrl-click handling (see links below).
But actually, if you need something that looks like a link and do something on click, but does not have a "target URL" (i.e. it shouldn't be right-clicked/ctrl-clicked to open in a new window/tab, or it wouldn't mean anything to do so), then do not use either an ANchor or Hyperlink, use a Label of whatever instead, and make it look like a link (but well, maybe you should use a Button and have it look like a button then; Google used to have link-alike buttons –such as the "refresh" link/button in GMail– and changed them to look like buttons when they really aren't links).
See also https://groups.google.com/d/msg/google-web-toolkit/P7vwRztO6bA/wTshqYs6NM0J and https://groups.google.com/d/msg/google-web-toolkit/CzOvgVsOfTo/IBNaG631-2QJ