[Isomorphic]

So to elaborate on what we said before, we don't have a solution for adding native HTML links outside widgets that does not involve a deep dive into native browser behavior, and if you were to go that direction, it's way outside of our charter to help.

And we also would not recommend spending effort on this approach. Enterprise applications tend to build up a lot of useful context in a page, and it's a focus on SmartGWT to re-use already loaded data wherever possible, for the best performance and scalability. Popping other browser tabs and browser windows works against this performance advantage.

If you want a tabbed interface, use a TabSet at the top level and provide normal SGWT menus to allow things to be opened in new tabs.

[csillag]

What are your expectations for further responses?

I would like to get an answer to this:

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.)

I understand that embedding true links without somehow damaging normal interactivity is really hard, so you consider that impractical, but what if I give up "normal interactivity", and just want the links for those widgets? Is it feasible that way? (Basically, I just need a link which looks like an IButton...)

[Isomorphic]

What are your expectations for further responses? Your questions have been answered, please read over the responses again.

[csillag]

update

I am still interested in 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]

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]

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.)

[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]

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]

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]

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]

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]

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]

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]

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.