adding links to buttons

[csillag]

Hi all,

I would like to add links to various items (mostly IButtons and tabs) in my application. These links should not influence the current behavior; their only
function would be that they can be opened in a new window/tab.

To make it clear: I can already address the surfaces of my application; this works very nicely. I can also copy the current address from the address bar, and open it in a new window. The address follows the changes of application state.

What is missing is only the ability to display (and copy) links to the addresses where the various already existing and working navigation elements would direct the user.

So, how can I add a link target to an IButton (and tabs in a TabSet, and rows in a ListGrid and a TreeGrid :), without changing the behavior of it?

Thank you for your help!

[csillag]

Any idea about this?

The situation once again:

- most states of my application are addressable.
- if I enter (or modify) the address in the address bar, the app goes to the wanted state.
- if I navigate the app via the controls, the address in the address bar is refreshed accordingly.

- The only missing thing is to actually declare the link on the buttons (and other things) so that it can be displayed in the browser's status bar when the user hovers above the link, and in can be opened in a new window/tab.

Ideally, adding the link to the controls should not change the current behavior (because they already navigate where they should go), but if this is not possible, it's also OK if the behavior changes to jumping to the link - because as I have written, this is also supported by the framework, and does the same.

[Isomorphic]

What's the purpose here? Solely to populate the browser status bar with a link that cannot be copied/pasted until the user clicks the button? Why do this?

Are you talking about a link *in addition to* the button or tab title, or making the existing title into a link? If the latter, since you say you don't want to change current behavior, what would click do: both switch the tab and pop up a separate window?

[csillag]

What's the purpose here? Solely to populate the browser status bar with a link that cannot be copied/pasted until the user clicks the button? Why do this?

The user should be able to copy the link. (Without clicking the button, of course.)
That's exactly the point: using the link, the user should be able to open a new window with a new copy of the application, where the new copy of the application would automatically go to the same state where the current copy would go, would the button be pressed.

Are you talking about a link *in addition to* the button or tab title, or making the existing title into a link? If the latter, since you say you don't want to change current behavior, what would click do: both switch the tab and pop up a separate window?

Ideally, the button should just call the click handler, the tab title should switch the tab, etc. The link should not play any direct role in the action, it's just there so that the user can see (and copy) it.

That's the ideal case. If this is not possible, it's also acceptable if the link just acts as a simple link: when clicked, takes the current window where it points to. (Since the application reacts to the history token changes, this would eventually result in the same behavior, as far as the user is concerned.)

However, in this case, the button basically stops being a button, which I do not really want, or need.

* * *

Please excuse me that I can not properly explain what I want; when I am ready, I will show you the working application, so you can see what I mean.

[Isomorphic]

I think we follow now. Would you expect the user to right click on the link and pick "Copy link location" to grab a link to spawn a new instance of the application? Because while that could work, it would prevent you using context clicks for other purposes (eg, it's fairly common to put a context menu on a tab).

[csillag]

I think we follow now. Would you expect the user to right click on the link and pick "Copy link location" to grab a link to spawn a new instance of the application?

Yes, either that, or just middle-click on it in Firefox, which means to "open link in new tab".

Because while that could work, it would prevent you using context clicks for other purposes (eg, it's fairly common to put a context menu on a tab).

Indeed, but I would only like to do this for the elements of the navigation system, and do not plan to use context menus on them.

I would like to add links to the following components:

- IButton
- TabSet tabs
- ListGrid records
- TreeGrid records

[Isomorphic]

In all these cases you can add HTML to the title attribute (button, tab) or add it via formatter APIs (grids), so you could add your own <a HREF> element. How you would handle event bubbling would most likely involve browser specific JS code added to the <a> - it could be rather involved, and you might be better off just adding SGWT-based menu options to spawn a new browser window / tab.

[csillag]

you can add HTML to the title attribute as add it via formatter APIs,

Could you please explain this a little bit more?

How you would handle event bubbling would most likely involve browser specific JS code

What if i don't handle it at all? In this case, would the link "fire", besides/instead of the previous behavior, or would something unspecified happen?

(As I have mentioned, it's also acceptable for me if the link takes over the previous behavior, because the same effect can be reached via other codepath, too.)

[Isomorphic]

There was a typo in the previous post, try re-reading it now that we've edited it and clarified.

As far as event bubbling, something unspecified would happen in both cases.

[csillag]

In all these cases you can add HTML to the title attribute (button, tab) or add it via formatter APIs (grids), so you could add your own <a HREF> element.

If I do that, only the text at the center of the button will be right-clickable, which can be a really small part of the whole button. I would like to add the <a HREF> element to the whole div constituting the button.

How you would handle event bubbling would most likely involve browser specific JS code added to the <a> - it could be rather involved,

Based on my previous experiences, I sure believe this. And I do not want to go there again. Ever. So, how about you handle this? (I am thinking about feature sponsorship for this bit.)

and you might be better off just adding SGWT-based menu options to spawn a new browser window / tab.

Can I emulate the one-click "middle button click" -> "open in new tab" behavior using current SGWT-based features? Can I intercept the clicks of the middle button at all?

Popping up a menu and having the user choose an option (from the list of one) feels too cumbersome to me. Directly adding the "open in new tab" function to the context click button would be confusing, because user expects this function to be on the middle click, and a menu on the right click.

[Isomorphic]

Do you have a particular set of users in mind who are used to middle-clicking? Not too many people know about that browser, operating system and hardware-specific shortcut.

Given that there is an alternative of creating normal SGWT UI elements for doing this, and given that embedding true links without somehow damaging normal interactivity could well be a deep dive into browser quirks and an ongoing maintenance nightmare, this would be an unlikely qualifier for feature sponsorship, sorry.

[csillag]

OK, so going back one step:

1. From the current set of SGWT features, what is the closest thing to a true HTML link? I add a context click handler, pop up a menu, show an option to open this in new tab? That's it?

2. If I give up the hope that the current interactive behavior can be kept, and just want to add a plain, simple HTML link to a button (not just the title, but the whole button), how can I do that? (I understand that with this, the default event handling will be displaced, so the click handler would not be called.)

[csillag]

IHow you would handle event bubbling would most likely involve browser specific JS code added to the <a> - it could be rather involved

On a second thought, when I have done something similar (5 years ago, in PHP), it was just a matter of adding an onClick handler to the URL. This way, the URL jump did not happen, and the handler was executed. This seemed to work in all popular browsers. (Then.)

What causes the problem here? (Again, I am not really into browser internals, so I am aware that I might be really ignorant about this.)

[csillag]

Do you have a particular set of users in mind who are used to middle-clicking? Not too many people know about that browser, operating system and hardware-specific shortcut.

Personally, I hate when I can not execute my usual breath-first search strategy on sites, because they do not provide true links.

[csillag]

update

I am still interested in this.