Hi Jerome, let me spend some words on your app, it looks really similar to the one we are implementing, the problem is that also the solution seems similar to my first approach. As I said in the post reply to my "problems with application like behaviour", I don't know how Icefaces work, then if this is not your scenario... simply ignore this reply. In my first solution I used the Tomahawk TabbedPane to handle my workspace application, every "sub-page" of the app lived in a tab inserted in the tabbedPane programmatically attaching a inner blind facelet composition inside the tab. In such behaviour, exactly as the one you described, I had to keep alive all the application in the same page (because the tab creation was created programmatically and handled intercepting actionlisteners and tabchangelisteners) and then I was not able to use meaningful outcomes (using meaningless or null returns) in my actions and (the worst) I had to handle by hand stuff like the Seam Context, the Seam Conversation and so on. This is evil for at least four reasons (and in my post i "tagged" it as DoNotDoThis): 1 - No outcomes, a) no stuff in faces-config to define page switch in a "natural" way in JSF b) no page-actions c) and in my scenario no way to connect a conversation to a tab (did you do that? How?), they were stateful beans; 2 - Minimum usage (and misuse) of Seam used as a facility to hold session data; 3 - (this probably is Tomahawk dependant) Strange behaviour like: the tags defined in a tab were correctly rendered the first time, but, selecting another tab and re-selecting the first one, the Tomahawk tags rendering were removed from the HTML and I had more than a problem also on Seam stuff (filling fields with injection and so on); 4 - The last and the worst: this approach is logically wrong. The usage of a rendering facility to handle such problems means move the behavioural logics of the application in a rendering tool instead of in the right place... In Seam, which has such purpose. Now, some words on my problem to solve: I have a menu and a tabbed view of my application, the selection of a menu item causes the first time the creation of a tab and after "refers to that tab" giving it the caption (it's also possible to add links in the tabs which work exactly as the menu items). Ok, at this point arrives the solution of the previous post I sent to you in my topic (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93666) or you can wear the breadcrubs conversation list to make it seem like a tabbed pane (but this shows all the conversations, then if you have other conversations not involved in the tabbed pane... you see them and you have to find a way to handle this). The question is: if you have the solution why you are waiting for a Gavin reply? I have at least one problem/nightmare which breaks this solution: I have to recycle some of my actions and some not: I have, for example, the manageThis action that can be called on some stuffIds and must create (the first time, and then refer to) a new tab for each stuffId, but I also have a manageThat action that is always rendered in the same tab regardless of the stuffId passed. In this situation I have to "pre-process" the request, identify or prepare for the creation the conversation (generating the correct id) and then redirect (without making another request turnaround; for this is great the page-actions) the flow on the correct action with the correct conversation id (created/retrieved on an algorithm logics, not on the behaviour of the page)... Everything works great but... The conversation list is an unmodifiable list in the request handling (I hope "at the moment" you can set the identifier of the conversation only on the request buondaries) and this causes the raise of an exception when I try to set the conversation identifier when the page-action drives the flow to the tab page; in the action handler I generate/retrieve the conversationId and, through the page-action, I switch to the @Begin method of the conversation with the right conversationId. I don't know if you have the same behaviour I listed above (and then if you have to wait for a Gavin reply or study another solution), but, in any case, if this is you scenario, I think that you are moving in a dangerous way (binding the behaviour on Icefaces) because is logically wrong, because if you write everything on your own you cannot ask for help, because you have to maintain your logics over the rendering improvements/modification of the tabbedpane rendering stuff and because it's error-prone. I hope this post will help you! Regards, Raffaele View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987257#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...