Because the underlying HTML DOM structure is different in 2.0 tab views, custom JavaScript code that uses window.frames collection or the getFrameObject() function to access the tab control instance will need to be changed to work with the new tabs. The tab control in 2.0 views is just a panel with an ID, and can be accessed as any other panel:
| View 1.0 format | View 2.0 format |
|---|---|
| var restriction = ...
var tabs = getFrameObject(parent, 'tabsFrame'); tabs.setTabsRestriction(restriction, 'page2'); tabs.selectTab('review'); |
var restriction = ...
var tabs = View.panels.get('tabs'); tabs.setTabsRestriction(restriction, 'page2'); tabs.selectTab('review'); |
In a 1.0 format tabbed wizard ), the selected tab page view is loaded initially. Each tab page view is loaded (and reloaded) each time the user selects the tab page.
In a 2.0 tabbed wizard that uses frames (tab/@useFrame=true) the selected tab page view is loaded initially. Other tab pages are loaded when the user selects them the first time, and never re-loaded again.
In a 2.0 tabbed wizard that does not use frames, all tab page views are loaded at the same time, after the master view is loaded, and never reloaded again. When the user selects another tab page, the first nested panel of the nested view is refreshed, but the nested view itself is not reloaded. This creates a code migration issue if the nested page view has a user_form_onload function that assumes that another tab page or pages were previously displayed and filled in by the user.
The simple way to migrate custom 1.0 tabbed wizard JavaScript code to 2.0 tabbed wizard code is to replace the user_form_onload() event handler by the user_form_onselect() event handler. The latter should be defined in the same nested view JS file as the former, and will be called whenever the user selects the corresponding tab page.