Mark Collette added a comment - 04/Apr/11 7:37 PM From brainstorming today, we came up with two different approaches. Both try to allow for a dynamic number of tabPanes, each of which could contain JSF components or alternatively an iframe. Once an iframe is loaded, we don't want it to be reloaded. The tabSet would be in a server mode, where tabPane contents are cached in the client, so that the iframe contents won't be updated, and tabPane contents are lazily loaded once they've been visited. Harder approach The tabSet renders the iframe element right into the tabPane content area. When a tabPane is visited for the first time, the content starts being rendered, whereas before it rendered an empty place-holder. Eventually, if every tabPane has been visited, then every tabPane's contents is being rendered. The dom diff ensures that only changed contents, which includes first time visited contents, will be sent to the browser. We could add a dom diff hint to not check and not send previously visited tabPane contents, so that we wouldn't have to render every visited tabPane's contents per lifecycle. But then the regular JSF taPane's would not really be interactive. Adding new tabPanes would cause dom diff to update all contents, since the count would change, so instead we either use empty place-holders for potentially added/inserted tabPanes, or we add insertion and deletion support, which would require dom diff and possibly bridge support. The empty place-holders would increase the rendered output, but not by a lot. The dom diff and bridge support for insertion and deletion could be an extensive effort. Bot would require component support. The application would need to inform the tabSet of inserted or removed tabPane components. Simpler approach The tabSet is used in regular server side mode. It does not specially render out place-holders for unvisited or to-be-added tabPanes. Changes to the count of tabPanes will cause the content area to all be updated. But, the cached contents are not actually rendered into there, they are instead rendered into a separate area, and made invisible. For the iframe scenario, we would use Ted's technique of a linked list of iframe elements, which can be added to without affecting a child count, using only dom replace operations, and which can be deleted from, by simply retargeting the iframe to a blank location, and ceasing to use it further. <div id="cachedCont_1"> <iframe id="cached_1"/> <div id="cachedCont_2> <iframe id="cached_2/> <div id="cachedCont_3> ... </div> </div> </div> In the javascript, we then listen for tab change events, and then place the iframe element inside the content area. Either by using absolute positioning, or by actually reparenting the element. Then make it visible. When tabbing away, hide it, and reparent it back if that's how we got it there. When an iframe tabPane is first visited, then it's added to the linked list and rendered into it. From then on we have to continue rendering that iframe, so it won't be dom differenced. Or we could add that don't-check-don't-update hint. We might not need a client side tab change listener if we just render that javascript from the server side as the selected tabPane is changed. We can generalise from iframe elements to any element, so that certain tabPanes can be marked as caching, so their contents are rendered into the protected area. Then we'd be manipulating arbitrary elements instead of iframes. Or could detect when the elements are iframes, if they behave as a special case. Most likely, while all of that can be automated, the application will still need to reveal to the tabSet component, when tabPanes have been inserted or removed. This is because, if a c:forEach is being use to build the tabPanes, their ids will ripple change when the tabPane list changes. Some method should be investigated for making the ids stick, so that they're not index based. If the ids were fixed, from using a data model id instead of index or generated id, then the tabSet could detect newly visited tabPanes and removed tabPanes itself.