Is the Multi-WindowTab support in Seam a flaw?

[andre66]

Hello dear Reader,

I've just read in the orchestra framework documentation, that the multi window/tab support
doesn't really work in the seam framework. So it is a flaw in the seam documentation.

Can somebody tell me more about that?

Thanks and Regards,

Andre

[kukeltje.ronald.jbpm.org]

you read in the orchestra framework documentation that seam multi window/tab support doesn't really work? And ask us if that is a flaw in the seam documentation... right?

Please point us to the documentation both the seam and orchestra ones, since I find it kind of weird and bold statement.

[andre66]

Hello Ronald,

I like Seam really and I am really enthusiastic of it, but in our application
is the multi-window/tab support very important so I read the documentation of
orchestra as well and I've found the following text under:

http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html
look at the Other Web Frameworks section.

For Seam I'm using the Seam in Action Book, and it writes positive about this functionality.

What should I do?
How can I test Seam if it does the right handling with multi-window/tab support.

I am new to Seam. I've installed the eclipse-ide for Seam and I've run the first
Logon example. How can I test the multi window/tab functionality?
Can you give me a hint, or a small example code which I can run to test this functionality.

Thank You and Best Regards,

Andre

[kukeltje.ronald.jbpm.org]

What they state could be true, I did not read all of the text. But in the paragraph above, they state that they use the same solution as seam does, encoding it in the url. So I think they did not intend to put seam down in any way.

The multi window issue is that they state it is hard to share e.g. conversations between windows/tabs since ending a conversation in one window does not automatically result in the other window nowing that. Multiple windows not sharing conversations but having their own, should not pose a problem. For me the latter comprises 100% of my usecases, so I never ran into this 'problem'. Besides that, I cannot remember anyone posting here and stating they ran into this, I think it is kind of a theoretical issue, but others might have a different opinion.

[christian.bauer]

Ronald van Kuijk wrote on Mar 27, 2009 12:36:


Multiple windows not sharing conversations but having their own, should not pose a problem.

Uhm, that's really the whole point of conversations, that you have one per window/tab hence, your session state is segmented by window/tab. You do NOT share a conversation in two windows, that's a programmer error.

[andre66]

So if I understood your statements right, there is in seam one session per user in an application, and to this session many conversation, one conversation per open window by the  user of the appropriate session.

Session per user is clear e.g. a cookie, and plus some window id.

How is this realized in Seam? Is javasript being used?

Thanks and Regards,

Andre

[kukeltje.ronald.jbpm.org]

@Christian,

Well, yes and no. The arguments they use in the orchestra docs are not about programmer errors, but user behaviour:

The user actions which are particularly problematic are:
  * Right-clicking a link and selecting 'open in new window' or 'open in new tab'
  * Bookmarking a page, then later opening a new page and activating the bookmark.
  * Copying the URL from the browser toolbar and pasting it into a new window

[kukeltje.ronald.jbpm.org]

the session is the cookie, the 'window-id' is for jsf a id in the url.

No javascript needed.

[christian.bauer]

Ronald van Kuijk wrote on Mar 27, 2009 13:25:

Right-clicking a link and selecting 'open in new window' or 'open in new tab

Perfectly fine, it's the programmers mistake if the link propagates the current conversation identifier and doesn't represent an entry point to a (new) conversation.

Bookmarking a page, then later opening a new page and activating the bookmark.

If the bookmark included a long-running conversation's identifier, there are several options available to the programmer how to handle it. By default you'd get a status message that says that this conversation was over.

Copying the URL from the browser toolbar and pasting it into a new window

That's the only one where I don't have a solution available immediately but I'm sure I'd find one if that really was a problem worth considering or if I'd think about it for more than 1 minute... and to tell you the truth, I sometimes use that behavior to move an existing conversation into a new window... it's a feature, not a bug :)

[andre66]

Thanks you for your answer!!!
I see, the multi-tab/window functionality of Seam is working right
when the user doesn't use the e.g. 'new tab/window' functionality.
Is it a server request necessary? With a server request is the problem solved?
E.G. we can solve this problem with javascript and ajax for example.
If the user is using the 'forbidden' functionality of the browser an ajax request could be sent to the server which fixes the problem and gets a new window id. (for the same session)
Would that be possible? What do you think?

Just one question if you don't mind!

Does it exist in Seam a conversation-object?
I mean in the sense of a session-object where developers
could store conversation specific information like navigation history
for a specific window in the application?

Best Regards,

Andre

[kukeltje.ronald.jbpm.org]

Christian Bauer wrote on Mar 27, 2009 13:46:

Ronald van Kuijk wrote on Mar 27, 2009 13:25:

Right-clicking a link and selecting 'open in new window' or 'open in new tab

Perfectly fine, it's the programmers mistake if the link propagates the current conversation identifier and doesn't represent an entry point to a (new) conversation.

yes and no... maybe I do want the current conversation identifier to be propagated, but in the current window. As a developer cannot prevent the right-click. Ok yes I can, but with al the plugins fro FF, people can circumvent that and since other functionality is also lost, lots of users hate this. So it is not perfectly fine, but not a major issue either (at least imo)

Christian Bauer wrote on Mar 27, 2009 13:46:

Bookmarking a page, then later opening a new page and activating the bookmark.

If the bookmark included a long-running conversation's identifier, there are several options available to the programmer how to handle it. By default you'd get a status message that says that this conversation was over.

Agreed, but it means it is not solved by the framework (not saying it should either.... I love seam)

Christian Bauer wrote on Mar 27, 2009 13:46:

Copying the URL from the browser toolbar and pasting it into a new window

That's the only one where I don't have a solution available immediately but I'm sure I'd find one if that really was a problem worth considering or if I'd think about it for more than 1 minute... and to tell you the truth, I sometimes use that behavior to move an existing conversation into a new window... it's a feature, not a bug :)

Exactly... No much effort should be put into things that happen seldomly.

[joblini]

Hi Andre,

This article presents the Seam Conversation model.

The link link you posted is certainly very useful in understanding the issues involved in providing multi-window support.

I agree with the remarks noting exaggerated claims made in some framework documentation.