making Anchor look like a normal link

[Matthew Pocock]

Hi,

I have several g:Anchor elements in my UiBinder design. I attach OnClick handlers to these to do interesting things. In the browser, these anchors are being rendered as <a> elements lacking an href attribute. When the mouse hovers over them, they don't do the usual link display things - the mouse icon goes into text mode rather than link-follow mode, and there's no blue underline. I tried adding a dummy href="" attribute, but although now they look like normal links, clicking on them follows to the url (in this case, a boring one) instead of the click handler. I want to have my cake and eat it - I want these links to look like links but react with my click handler. Is there a trick for this?

Thanks,

Matthew

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Derek]

I set href to "javascript:;". You could instead use CSS to style the
cursor to be a pointer to make it look real, but javascript:; is the
quickest and easiest.

Derek

On May 17, 7:40 am, Matthew Pocock <turingatemyhams...@gmail.com>
wrote:

> Hi,
>
> I have several g:Anchor elements in my UiBinder design. I attach OnClick
> handlers to these to do interesting things. In the browser, these anchors
> are being rendered as <a> elements lacking an href attribute. When the
> mouse hovers over them, they don't do the usual link display things - the
> mouse icon goes into text mode rather than link-follow mode, and there's no
> blue underline. I tried adding a dummy href="" attribute, but although now
> they look like normal links, clicking on them follows to the url (in this
> case, a boring one) instead of the click handler. I want to have my cake
> and eat it - I want these links to look like links but react with my click
> handler. Is there a trick for this?
>
> Thanks,
>
> Matthew
>
> --
> Dr Matthew Pocock
> Integrative Bioinformatics Group, School of Computing Science, Newcastle
> University

> mailto: turingatemyhams...@gmail.com
> gchat: turingatemyhams...@gmail.com
> msn: matthew_poc...@yahoo.co.uk

[Matthew Pocock]

Thanks Derek. As a variation on a theme, this also works: href="javascript:void(0)".

Matthew

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

[Thomas Broyer]

On Thursday, May 17, 2012 1:40:39 PM UTC+2, Matthew Pocock wrote:

Hi,

I have several g:Anchor elements in my UiBinder design. I attach OnClick handlers to these to do interesting things. In the browser, these anchors are being rendered as <a> elements lacking an href attribute. When the mouse hovers over them, they don't do the usual link display things - the mouse icon goes into text mode rather than link-follow mode, and there's no blue underline. I tried adding a dummy href="" attribute, but although now they look like normal links, clicking on them follows to the url (in this case, a boring one) instead of the click handler. I want to have my cake and eat it - I want these links to look like links but react with my click handler. Is there a trick for this?

If your "links" navigate in your app, then you should set the href to be the target history token. Otherwise, you shouldn't use a link, which means you shouldn't use an Anchor. Use a Label, InlineLabel, Button, PushButton, or CustomButton instead, and style it like to look like a link if that's what you want (but then beware that you could confuse users, as things that look like links should behave like links –including the ctrl+click and right-click to open the target in new tabs/windows, add the target as a favorite, or copy the target URL to the clipboard–; Google had it wrong in GMail –they used <span>s at the time I looked at it, they might had used <a>s before that– and in one of their redesign iterations –even before the "gray" overhaul– they fixed it by using buttons that looked like buttons for actions, and use true links for navigation).

href="javascript:;" sure does work (and Anchor has a –legacy– constructor that will use that), but I'd discourage its use if you care the slightest bit about accessibility (and/or semantics).

In any case, with you should preventDefault() on the event to disable the navigation done by the browser on links, if you already do it in your code. This is what Hyperlink/InlineHyperlink do.

[Mike Dee]

Here is the confusing thing about links (HyperLink and Anchor).  Picture a simple CRUD situation where one does a search, the search results appear, and one can click on "something" to be shown the details.  When Hyperlink is right-clicked, the usual options appear.  If an app requires authentication (basic cookie/session stuff) and "open in another tab" or "open in another window" is selected, it doesn't work.  The newly opened tab goes to the log on screen.  Open in new Tab/Window has the same basic effect as doing a refresh (F5).

I find the Hyperlink documentation and discussions about Hyperlink confusing in that regard.  They explain that Hyperlink is supposedly for internal linking (within an app).  Open in new tab/window should be allowed.  The result of opening in a new tab/window should be to bring the app to the appropriate state in the new tab/window.  

But they don't talk about this authentication issue.  Is there a recommended way to handle this using Hyperlink/Anchor?  Or, should a Label (ClickableText, maybe) be used in such a situation?  Or something else?

Mike

[Thomas Broyer]

If loading the app (when you're authenticated) doesn't bring you to the place the URL represents, then your app is broken.

Your issue is either with auth or app initialization, not with hyperlinks.

Google Groups for instance brings you back to where you were when hitting F5.

[Joseph Lust]

Depending on how you're implementing your hyperlinks (if they are foo links), then you could add a method to your handler to first check if the user is authenticated, and then forward them to the target of the link. Of course foo links would need to be considerate of the CTRL+click, middle click, left click, history activities the user expects. In the case that you are not authorized to see the content of the link (i.e. session expiration), then you could open a popup for the user to authenticate.

Sincerely,

Joseph

[Mike Dee]

Actually, I made a mistake.  The problem doesn't seem to be the authentication (which simply checks the session).   I disabled the authentication and it still happens.

I believe this is the way GWT is supposed to work.  A GWT is one page.  The going back and forward through pages is simulated by the Places mechanism.

What happens with a Hyperlink when opening in new tab/window is a hard reload.  This is the same as cutting and pasting a URL (once inside the app) into a new tab or window.  GWT calls onModuleLoad().  That's the way GWT works, unless I fundamentally misunderstand it.

The confusion about Hyperlink remains.  What is an internal link to the app supposed to do when opening in new tab/window?

[Joseph Lust]

If you're using Activities and Places, you can have a link like http://www.yourApp.com/entryPoint.html#stateInfo=something 

The state information in the URL triggers the page to load to a specific point, the exact same as this Google Groups page does. That way, opening the link would open a new window and jump to the desired point in the application. Obviously however, only open a new page if you really need one, since the application will need to load again and it would be faster to just change to that state in the current open application window.

Sincerely,

Joseph

[Mike Dee]

And opening a new window is when authentication comes into play.  The user hasn't logged into the new instance of the application (opened in the new window).  Hence we are back to the original problem.

With a regular web app, this wouldn't be a problem.  The state of whether the user is logged in is maintained on the server (in session variables).  In the case of GWT, the state of whether the user is logged is in maintained on the client.

[Thomas Broyer]

On Monday, June 4, 2012 12:06:42 AM UTC+2, Mike Dee wrote:

And opening a new window is when authentication comes into play.  The user hasn't logged into the new instance of the application (opened in the new window).  Hence we are back to the original problem.

With a regular web app, this wouldn't be a problem.  The state of whether the user is logged in is maintained on the server (in session variables).  In the case of GWT, the state of whether the user is logged is in maintained on the client.

Not necessarily; and if you're doing it that way, then IMO you're either "over-secure" (at the detriment of UX, which is fine if it's a conscious choice) or you're doing it wrong.

First, I find it way easier to handle authentication separate from the GWT app, and just consider the user is logged in when/if it loads the GWT app. That way, you only have to handle the case that the user has been disconnected and tell him to refresh the page in order to re-authenticate. And if you open the app while you're already authenticated (using cookies or whatever, but this is dealt with the server, unknown to the GWT app) then it "just works": the GWT app does not know (and does not need to know) whether you just authenticated or you reloaded the page, or went back to the app while your authentication session was still active, or opened the app in another window/tab; it just loads, and you're authenticated.

But even if you handle authenticating from within the app, you can very well set a cookie after authentication and check it onModuleLoad (I did it once, it works, in practice, not only theoretically).

[Mike Dee]

I think I understand what you are saying.  In this case, the app is a medical app and there are requirements that the app timeout after a period of inactivity (which is usually short: 15 to 30 minutes).  When logging in, an event is triggered and the app state is "logged in".  Currently, the timeout isn't implemented, but the app does check the session on each RPC call.  When the session doesn't exist (is expired) the app state is "logged out".  The way it works now is pretty good...except for linking within the app.

I'll need to think about what you suggest (setting a cookie after authentication) to figure out how to do it.

[Mike Dee]

Just thinking.  When right-clicking a Hyperlink, which starts a new instance of the app in a separate window/tab, how would one figure out the user (that is logged in to the original instance)?  I assume the new instance starts up (onModuleLoad()) and knows nothing about the instance from which it was started.

One idea is to pass the user on the URL, but would that be secure?  Is there a standard way to do this?

[Mike Dee]

Actually, I think the answer is here:  http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ