Home » Eclipse Projects » Remote Application Platform (RAP) » RAP detach parts to a new window(Possibiltiy to detach a part to a new (browser) window.)
|
Re: RAP detach parts to a new window [message #1282411 is a reply to message #1281744] |
Wed, 02 April 2014 09:00 |
Tim Buschtoens Messages: 396 Registered: July 2009 |
Senior Member |
|
|
Hi.
You can certainly start another entrypoint from the same application (or
the same entrypint with a parameter) using the URL launcher. That way it
should be feasible to implement such an UI on application level.
But I guess what you want would be out-of-the-box support to display
some widgets or maybe an entire shell of the same UI-Session in another
tab. That is technically not possible because the server would have to
send some part of an HTTP response to one tab, and some other part to
the other tab. (Yes, you can do something like that with ServerPush or
web sockets, but at that point you're basically back to what I described
at the beginning, just more low-level and complicated.)
So if you try implementing something like this as part of your
application (or an underlying framework) I can certainly give you some
hints, but out-of-the-box support is not a realistic possibility I'd say.
Greetings,
Tim
Am 01.04.2014 11:41, schrieb René Brandstetter:
> Hi all,
>
> I know that a lot of effort was put into the support of multiple Browser
> tabs, but are there any investigations to support something like detach
> parts of an UI to a new Browser window/tab without automatically
> starting a new application? Which means move a part to a new browser
> window/tab and stay in the same RAP application, so a user can move
> parts of the RAP UI to a new browser window and arrange them as he wants?
>
> Regards
> René
--
Tim Buschtöns
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
| |
Re: RAP detach parts to a new window [message #1286941 is a reply to message #1282411] |
Mon, 07 April 2014 08:08 |
René Brandstetter Messages: 17 Registered: July 2012 |
Junior Member |
|
|
Hi Tim,
I tried your suggestion with the URLLauncher but within our application it will not work, because
- we have a login-screen, which will than always show up in the detached windows and
- we use the workbench instead of building a custom application based on RWT-Widgets.
So this solution will cause a second login and a second workbench.
After that, I started to play with the JavaScript and I was able to open a new window which uses the original JavaScript elements from it's opener. This allowed me to reuse the singleton instances, especially the rwt.remote.Connection instance, and so the Connection-ID and the Request-Counter always use the correct values. With this solution I managed to move only the required HTML-elements of the part to the new window. Installing the right listeners on the new HTML-Window also allowed me to handle the UI events (selection, click, move, ...) but what I couldn't fix was the problem that all tooltips and popups open in the main window instead of the detached window. I found the reason for this behavior but I couldn't find a solution for it at the moment. The reason for this lies in the HTML representation of those elements because tooltips and popups reuse the one HTML element which is only added at the main-window and not in my detached one.
If you think this is a solution which is worth some further investigations, please let me know and I will ask my manager if we can make some contributions with the help of your company.
Regards
René
|
|
| | | | |
Re: RAP detach parts to a new window [message #1310501 is a reply to message #1309008] |
Wed, 23 April 2014 08:15 |
René Brandstetter Messages: 17 Registered: July 2012 |
Junior Member |
|
|
Hi,
moving around DOM elements or JavaScript objects shouldn't be a big problem, because with window.open() it's still the same browser process (and as you can see with window.opener you have access to the origin window). A problem arises with the "singleton"-UI elements, like Popups or Tooltips, because there you don't know in which browser window the actual DOM element is located.
This prototype is heavily concentrating on the workbench, because our software is based on this. But I can imagine something like a RWT Client-Service named "DetachWindowService" which has methods to detach elements like Windows, Wizards, Parts, .... This service could afterwards be used by the developers who use plain RWT and want this behavior or by the workbench to allow detach Parts via Drag&Drop. (Maybe it could also be integrated into the default behavior for opening Shells, e.g.: a server property which will automatically open a new browser window if a developer opens a new shell in its code.)
Regards
René
|
|
|
Re: RAP detach parts to a new window [message #1312648 is a reply to message #1310501] |
Thu, 24 April 2014 12:17 |
Tim Buschtoens Messages: 396 Registered: July 2009 |
Senior Member |
|
|
Am 23.04.2014 10:15, schrieb René Brandstetter:
> Hi,
>
> moving around DOM elements or JavaScript objects shouldn't be a big
> problem, because with window.open() it's still the same browser process
> (and as you can see with window.opener you have access to the origin
> window). A problem arises with the "singleton"-UI elements, like Popups
> or Tooltips, because there you don't know in which browser window the
> actual DOM element is located.
For those maybe we need to have one for each window, but I think these
are solvable problems for a later stage.
> it could also be integrated into the default behavior for opening
> Shells, e.g.: a server property which will automatically open a new
> browser window if a developer opens a new shell in its code.)
I would like to avoid introducing a ClientService for this. It could
work like the MARKUP_ENABLED property (can be enabled for a Shell after
it's created, but not changed later.) However we also need to consider
that if this project does not live within the RAP core from the
beginning we can't change server internals (which would be required for
this), so a static Class would be better for the beginning. E.g.
DetachedShellFactory.create()?
I would also like to talk unit tests, which are very important to us. We
use TDD most of the time. Are you in any way familiar with how we write
JS tests? We recently started using Jasmine for testing new features
(which I would consider this is, even though it may require some changes
to existing code).
Greetings,
Tim
--
Tim Buschtöns
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
Re: RAP detach parts to a new window [message #1324092 is a reply to message #1312648] |
Wed, 30 April 2014 15:56 |
Tim Buschtoens Messages: 396 Registered: July 2009 |
Senior Member |
|
|
I tried to create a JavaScript test bundle to kickstart TDD, but it's
not possible as long as the bundle with the JS in it has dependencies to
workbench. If you can make a split so that the bundle with the detach
code has only dependencies to org.eclipse.rap.rwt I can push it. (I
forked your git rep.)
Greetings,
Tim
Am 24.04.2014 14:17, schrieb Tim Buschtöns:
>
>
> Am 23.04.2014 10:15, schrieb René Brandstetter:
>> Hi,
>>
>> moving around DOM elements or JavaScript objects shouldn't be a big
>> problem, because with window.open() it's still the same browser process
>> (and as you can see with window.opener you have access to the origin
>> window). A problem arises with the "singleton"-UI elements, like Popups
>> or Tooltips, because there you don't know in which browser window the
>> actual DOM element is located.
> For those maybe we need to have one for each window, but I think these
> are solvable problems for a later stage.
>
>> it could also be integrated into the default behavior for opening
>> Shells, e.g.: a server property which will automatically open a new
>> browser window if a developer opens a new shell in its code.)
>
> I would like to avoid introducing a ClientService for this. It could
> work like the MARKUP_ENABLED property (can be enabled for a Shell after
> it's created, but not changed later.) However we also need to consider
> that if this project does not live within the RAP core from the
> beginning we can't change server internals (which would be required for
> this), so a static Class would be better for the beginning. E.g.
> DetachedShellFactory.create()?
>
> I would also like to talk unit tests, which are very important to us. We
> use TDD most of the time. Are you in any way familiar with how we write
> JS tests? We recently started using Jasmine for testing new features
> (which I would consider this is, even though it may require some changes
> to existing code).
>
> Greetings,
> Tim
>
--
Tim Buschtöns
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
| | |
Goto Forum:
Current Time: Thu Mar 28 15:35:54 GMT 2024
Powered by FUDForum. Page generated in 0.04846 seconds
|