Foundset synchronization between multiple windows

Classic Servoy
1

All,

We have a situation where we’re opening a second non-modal window that shares its foundset with the main window. On the main window we’re displaying a detailed list while on the secondary window we’re displaying a map (leveraging a plugin similar to http://code.google.com/p/web-client-utils/) that allows the user to visualize and further refine their foundset. The reason for using two separate browser windows like this is that a large portion of our users have dual monitor setups and this allows them to easily leverage them. The big problem with this is that the foundset updates are not synchronized immediately between the two windows. In fact, it can take up to 5 seconds (the default servoy.webclient.datanotify.frequency setting) for an update in one window to appear on the other. Even worse, the user can crash application completely (under v4.1.3) simply by performing an action that updates the foundset in one window and then performing another action in the other window prior to it being updated. The situation has improved slightly under v4.1.4 in that users can no longer trigger a crash (at least they don’t get an “Internal Error” page) but still the window will remain non-functional for some time with “Error Calling Server” messages reported in the top right-hand corner of the window which is frustrating from a user standpoint.

Ideally we’d like to see all browser windows to be updated simultaneously rather than each window polling for updates separately. Do any Servoy experts know of a way to get this working type of solution to work properly?

Thanks,
Corey

2

Thats not really possible currently

1 window doesn’t have know about the other and if it did then it wouldnt know what that window would display.
Also the browser window doesnt really know that you changed something in the backend. that only the server knows
And on the server an individual component of a page then knows it has to render but thats pretty much it.
(you cant that say on the server to all the pages do update yourself because there is no direct connection to the browser window, they have to wait for the browser window to do that)

Maybe in the future we can use things like Comet so that there is a constant open connection between a browser window and the server.
But for this to be reliable we need to use the next version of tomcat thats build on the coming spec of the servlet api (servlet 3.0)

Maybe you can build in plugin for this where you can say now update also the other pages at the moment you know that it should do that.

3

Hi Johan,

jcompagner:
Maybe in the future we can use things like Comet so that there is a constant open connection between a browser window and the server.
But for this to be reliable we need to use the next version of tomcat thats build on the coming spec of the servlet api (servlet 3.0)

Comet support would be a great addition to the web client. Tomcat 6 already supports Comet though of course that’s not a standardized version of the API but that may not be an issue if you’re planning on continuing to bundle Tomcat with Servoy. The current polling solution is inefficient especially since each dialog/window that’s opened seem to do their own polling. Is there any concrete plan to implement a Comet-based solution in an upcoming release? Ideally, there would only be one Comet connection per browser session regardless of how many windows are open.

jcompagner:
Maybe you can build in plugin for this where you can say now update also the other pages at the moment you know that it should do that.

Can you give any pointers or describe how we should approach this? So far we have an incomplete solution using the aforementioned web-client-utils plugin to send a Javascript snippet to the browser:

function manipulateFoundSet()
{
  // update the foundset...
  .
  .
  .
  // force an update on the main window
  plugins.webclient.executeClientSideJS(
    "if (window.opener) window.opener.triggerAjaxUpdate();");
}

This only allows us to force an update on the parent browser window unfortunately. Does Servoy web client track all opened windows on the client side anywhere?

Thanks for your help.

Corey

4

Yeroc:
Comet support would be a great addition to the web client. Tomcat 6 already supports Comet though of course that’s not a standardized version of the API but that may not be an issue if you’re planning on continuing to bundle Tomcat with Servoy. The current polling solution is inefficient especially since each dialog/window that’s opened seem to do their own polling. Is there any concrete plan to implement a Comet-based solution in an upcoming release? Ideally, there would only be one Comet connection per browser session regardless of how many windows are open.

yes i know that there is some things for that
The http tunnel was first build on that. But we had to rewrite it completely because of so many problems and now the tunnel uses the “old” approach and it is working way better
So currently i am not going to build on that again and will wait until it is more final.

I dont think it is that easy to have 1 connection over all browsers windows/tabs. That will update then all the windows, The client side doesnt know about all the windows, and which window does all the work?
If you close that window then how do others know that there is no Comet connection anymore? That could be very confusing for a user.
Besides all that we have to really look if communications and updates between pages are all always working in all the browsers we have to support.

Yeroc:
Can you give any pointers or describe how we should approach this? So far we have an incomplete solution using the aforementioned web-client-utils plugin to send a Javascript snippet to the browser:

function manipulateFoundSet()

{
// update the foundset…
.
.
.
// force an update on the main window
plugins.webclient.executeClientSideJS(
“if (window.opener) window.opener.triggerAjaxUpdate();”);
}



This only allows us to force an update on the parent browser window unfortunately. Does Servoy web client track all opened windows on the client side anywhere?

No the client doesnt know
You can just right click open in new tab on some stuff.
Or just type in in a new tab another url to your solution.

there are so many ways that there can be tabs or windows

And this is again the same thing as 1 connection. Where to track that opened windows? All windows should know about all others but that will must be synced up then constantly,
or 1 window to track it all but if you close that one then you loose all of them again.

What people should try to do is not use multiply windows… really in an full ajax application you should try to use 1 page that does it all. (with modal dialogs for the dialog stuff)
in the default FF behavior i find opening tabs very annoying because i can have 10 tabs open then my main window is the 4th.
Then if i open a tab the next tab is by default i think 11 so suddenly you have a tab at position 4 and 11 that belongs to each other… if i then at 11 you have to search and search how to get back to 4.
(i dont allow a web client to open a window, it always have to be a tab)

Another tab is really a new application. At least many in the wicket world really want that (so that you can login twice under different names or have different solutions open) but this is hard to reliable track in a browser.

5

jcompagner:
No the client doesnt know
You can just right click open in new tab on some stuff.
Or just type in in a new tab another url to your solution.

there are so many ways that there can be tabs or windows

We are only concerned about tracking windows explicitly opened via application.showFormInDialog() calls.

jcompagner:
What people should try to do is not use multiply windows… really in an full ajax application you should try to use 1 page that does it all. (with modal dialogs for the dialog stuff)

I agree. In our case this is what the client wanted. Since they have dual monitor setups they wanted to be able to have the main window open on one monitor with a related map display open on the second monitor. While not conventional for a web application on the surface this seems like a reasonable request.