APEX 19.2 / 23.2
We are working on an APEX 19.2 application. It currently has a feature wherein a button on a main page opens a primary unchained modal dialog page containing a DML form, a classic report, and another button. That button opens a secondary unchained modal dialog page, containing a further DML form. Opening, submitting, and closing these dialogs works exactly as required.
An enhancement request has been raised that asks for the main page to also allow for the invocation of a multi-stage wizard, where the final step would be the current secondary modal dialog.
I have reproduced a simple demonstration of this scenario on apex.oracle.com, in its current 19.2/UT 1.4 implementation, and an upgraded 23.2 version to check future compatibility. The demo pages play the following roles:
- 1: Home/Main page
- 10: Initial Wizard dialog page (chained)
- 11: Intermediate Wizard dialog pages (chained)
- 20: Primary form dialog page (originally unchained, now chained)
- 100: Secondary form dialog page (still unchained)
I planned to change the configuration of the original dialog pages (20 & 100) from unchained to chained, with the secondary form (100) replacing the primary (20), and then branching back to it. However, after building the wizard pages and hooking everything up I was surprised to find that although the secondary form (100) was working as expected in its new guise as the final step in the wizard, when invoked via the original button on the primary dialog (20), it still popped up on top as a separate dialog. On checking I found that I had neglected to enable the Chained property on page 100.
The current functionality can be simulated by clicking the Home page Open Primary Dialog button, followed by the Unchained Dialog page on the primary dialog.
I know what can/can't/should/shouldn't be done when navigating between modal pages, but this is a configuration I haven't encountered before. The unexpected outcome where the unchained page (100) appears to work correctly in both cases is intriguing, because there are reasonable grounds for keeping the original (page 20 calling nested page 100) behaviour after adding the wizard:
- Operators are used to it.
- Page 20 and the current data it contains is still visible when page 100 is opened from it.
- It's easier to implement as there is no additional logic to determine whether to run a Close Dialog (wizard mode) or branch (page 20) on submission of page 100.
Not being sure whether this was a valid scenario, I did some research and found a 2015 article by @john-snyders-oracle which says:
The normal pattern for using dialogs is that it is OK for the calling or parent page to know about the dialog page, but not the other way around. The dialog should not know the context from which it is used. If a dialog page knows about the page it is called from then it limits how the dialog can be reused. This is not APEX specific; it is a common UI framework pattern but is often ignored in web apps. This means that if you are trying to take data entered in a dialog and insert or use it in the parent page, this should be done from event handlers or dynamic actions on the parent page not from code on the dialog page. You should not try to use JavaScript on the dialog page to try to manipulate the parent page.
…
There is a small way in which APEX modal pages break this normal pattern. The Chained property is an example of the dialog specifying how the parent is going to use the dialog. In a traditional desktop framework it would be the caller that would decide if the dialog should open as a nested dialog (not chained) or replace the current dialog (chained). In APEX it was far more important to be able to open dialogs with just the existing metadata (the page number). The impact is that it is not possible to use the same dialog page as a step in a wizard in some cases and as a nested dialog in other cases. The need to do this should be very rare.
I'm in complete agreement with the last sentence: the need to do this is very rare as it's the first time I've encountered it in eight years of using APEX dialogs.
The second last sentence however seems to rule out doing this at all, yet we appear to have working examples. Note that neither the wizard nor the nested dialog case violates anything said in the first paragraph: all of the data is passed from the calling pages or captured in the dialog, and all of the subsequent processing is self-contained in each dialog or wizard page.
So is this considered a safe and supported scenario?
If so, has something changed since 2015, rendering that part of the article obsolete?
Or is this just another quirk of dialog implementation as discussed in the linked thread above (e.g. it only “works” because page 100 is the last step in the wizard)?