The module IATools was initially created to simplify creation and usage of tab interfaces in User Application/RBPM. Its usage is simple - either embed the code inline in a form's script tab or save it in a web server's URL and point to it as an external resource. After that call the initial setup and start building and linking the different form elements into the desired tabs.
The module also comes with a sample workflow export that demonstrate the tab UI capabilities (with a simple, non-production CSS example for the tabs) as well as its picklist management capabilities.
Just go to https://github.com/fchierad/IAtools, download the desired file ( IAtools.js for lab/dev/ease of debugging, IAtools.min.js for production usage) and we can start. For this post I will be using the sample workflow provided with the library to explain its basic features, look at the libraries README.md file for further documentation on its functions.
The first step to use the library is to create a workflow, then a form and go to the Scripts tab. Click the sign and paste the contents of the selected library (will be using IAtools.min.js for this post).
This will create an ECMAScript object in the global scope named IAtools, and all the functions/APIs we will use are part of said object.
Since the library needs to be initialized with the RBPM framework objects to be able to work properly, next order of business is to add a form-wide onload event that passes these objects to the scripts, then capture them and pass the same to the library's init() function:
The tab UI functionality returns the HTML for the tabs to be inserted into a form's HTML field, and can be initialized in many ways. First we will create a function to instantiate the tab factory module, and with that instance we can append the information necessary for the different tabs and which fields will be inside them. Our end goal for this example is to have something like the images below, that we can then use CSS to provide proper theme and desired appearance. By default the library applies the CSS classes 'navbar', 'navitem', 'navactive' .in the tab control. We can change their actual names per instance by using the function setCSSClassName() .
First step in our function that will return the tab HTML exported functions to enable its behavior is to create a variable that holds a reference to the tabFactory API set. Then we can call the function addTab(id, name, order, fieldlist, cb) with its different parameters to add in-memory the tabs we want to create:
The first parameter is the tab's ID, the second parameter is the Display name seeing in the UI, the third parameter is a number to force a certain order to the tabs (it does not have to be the insert order.
After that we have a few different approaches to work with the tabs - we can provide the names of the fields per tab, as they appear in Designer, and later setup these fields to react to certain events that will handle their visibility, that would use the 4th parameter that accepts an array. We could leave the array empty ( pass  as the parameter) and instead provide a callback function to be executed when the tab is selected/de-selected. When the callback function is called 2 parameters will be passed to the same - the tab's ID and a string parameter. When a tab becomes active the second callback parameter is 'enter', when it becomes inactive the second callback parameter is 'leave'. Lastly we could mix both approaches, using one for visibility and the other for additional effects we want to occur when the tabs change.
For this example the approach chosen is to pass an array of field names to the addTab function. This approach has the advantage of self-documenting what the code is doing. This also means we need to setup events to handle the visibility of the form fields that will be switched as we click on the different tabs. The module does provide a function to make that task simpler - fieldVisibility(). To use the same just add an event to the form field with the code IAtools.fieldVisibility( event, field ); as shown below:
All fields that will be part of a tab need their own visibility event. It is possible to have multiple fields with the same event, I just happen to prefer to have fine-grained control per field. After linking the visibility events on the necessary form fields we can let the tab control know their names and which fields they correspond to:
Now if we already have the proper CSS to style the tabs with the desired appearance we can call getTabHTML() and set its return value on a form string-HTML field. Since in this example we don' t have any CSS aside form what comes with RBPM itself, we will use getSampleCSS() to obtain very simple, basic styling for the tabs (the one seen in the screen shot further above).
It is possible to initialize the contents of the HTML field in many ways, for this example instead of calling the function from inside the field's own "HTML Content" property it was chosen to set it up during form initialization along with other tasks:
The library has also a few function to facilitate moving data between picklists, will leave as an exercise to the reader to import the sample work flow, play with the tabs and picklists then check the script's comments on how/why they are setup this way.