Forum Stats

  • 3,769,603 Users
  • 2,252,991 Discussions
  • 7,875,117 Comments

Discussions

Branching to Modal

Pavel_p
Pavel_p Member Posts: 2,311 Gold Trophy
edited Aug 4, 2017 9:30AM in APEX Discussions

Hi all,

this is a followup to this thread and mainly to this @John Snyders-Oracle blogpost Passing Data in and out of APEX Dialogs – HardLikeSoftware . There are some parts that make me really confused, especially

Note: Anyone working with APEX 5.0 and dialogs for a while now should know that you can’t use a server side branch to redirect to a dialog page.

Yes, I noticed that but considered it as a bug.

You may be surprised to find that in 5.1 it does work in some cases.

Well, I definitely was not surprised, I just thought the "bug" was fixed in 5.1.

If the page attribute Reload on Submit is Only for Success then it will work.

I just tried it and it seems correct. Well, "the bug" was corrected only partially. Btw, the error produced is really cryptic (Corrupted Content Error) and I would have never ever found there is some connection between the the Reload on Submit page attribute.

Before you think that this is some cool new 5.1 feature let me tell you this is a mistake; an unintended consequence of how reload on submit only for success works. I was surprised to find that this works. You should not rely on it working in the future. So to be clear do not branch to dialog pages.

Well, to be honest, there seem to be a lot of things in 5.1 that cannot be relied on anymore. But modal pages were one of the main changes in 5.0, so I would automatically expect that they support standard APEX things like branches. Also there is a packaged app Sample Dialog where on the (modal) Page 8, there is a Submit button and then a branch to another modal page (9). So is it valid to create a branch from modal to another modal, while branching from normal to modal is not recommended? I'm completely confused and it would be highly helpful if someone from the development team could make things absolutely clear.

It would be nice if there was some branch validation implemented in the IDE to avoid any confusion.

Thanks a lot,

Pavel

matze276PMON

Best Answer

  • John Snyders-Oracle
    John Snyders-Oracle Member Posts: 1,408 Employee
    edited Aug 3, 2017 7:42PM Accepted Answer

    Hi Pavel,

    I will try to clear things up. As I have said before modal dialog pages are complex.

    First I must reiterate that it is intended that a server side branch cannot open a modal dialog page. This is not a bug so there was nothing to fix in 5.1. There is a special case, as you have pointed out, where a modal dialog page can use a server side branch to another dialog page. This has special semantics where the branch page replaces the current modal page inside the iframe. I'll explain how this works and why it is allowed.

    What a submit + branch (redirect) means and how it works:

    The browser is going to unload the current page, posting the form data to the server and receive a response that contains in the location header the url of a new page to load. (The browser makes two requests first post then get new page.) The urls to open a modal dialog are actually javascript code to run. In a link this works because the url uses the javascript: scheme so the browser executes the code. In a button the url is set as the onclick attribute which works because the javascript: is treated as a label and ignored. But a browser (the http protocol) doesn't allow the javascript scheme in the location header and that is why you get an error from the browser if you try. (Yes the error is cryptic but we have no control over the text - it is a browser message. But as you say we should implement branch validation so that it can't happen.)

    Now in 5.1 we changed how pages are submitted to support interactive grids but we tried to keep the semantics of submit + branch (redirect) the same. The intent is to be able to get validation error information in the response without the current page having been unloaded first. But in the case where there is no error we redirect to the new url. This works by using ajax to "submit" the page and then either displaying error information or redirecting to the url returned in the ajax response. This new way does not do a normal form submit and the response does not use the location header.

    It doesn't make logical sense to branch to a modal dialog in submit + branch. Because opening a modal dialog page assumes there is a current page to popup over (insert an iframe into the DOM and make it a modal pop over) but submit + branch means to unload the current page and replace it with the new one. For this to make any sense you would either need to specify, as part of the branch, the new page to load and the modal page to open as soon as the new page is loaded or assume that the current page is going to remain current and open the dialog. Both these things are completely different from what submit + branch means.

    So why is it OK for a modal dialog page to branch to another modal dialog page and how does this work:

    The wizard pattern is very common and needs to be supported. The term we use is chained dialog. Each dialog page that is part of the wizard reuses the same dialog. In this case it is the iframe page that is being replaced not the main page so the logical inconsistency mentioned above doesn't exist; there will be a page to popup over. It works because there is a special case in the response returned from the modal dialog page submit. Because the page is in an iframe in a dialog it must return some code to execute after the submit. The code either closes the dialog or replaces the iframe with the next page. You can see this by inspecting the response to the POST request. It contains the code to execute such as:

    <script type="text/javascript">

    <!--

    apex.navigation.dialog.close(true,function(pDialog){ apex.navigation.dialog("f?p=42083:9:...",{title:"Confirmation",height:"480",width:"720",maxWidth:"960",modal:true,dialog:pDialog},"t-Dialog--wizard",this); });

    //-->

    </script>

    If the response did not contain this code the dialog would never close.

    I hope this clears up any confusion.

    Regards,

    -John

    Toufiq - Hexagon PPM

Answers

  • John Snyders-Oracle
    John Snyders-Oracle Member Posts: 1,408 Employee
    edited Aug 3, 2017 7:42PM Accepted Answer

    Hi Pavel,

    I will try to clear things up. As I have said before modal dialog pages are complex.

    First I must reiterate that it is intended that a server side branch cannot open a modal dialog page. This is not a bug so there was nothing to fix in 5.1. There is a special case, as you have pointed out, where a modal dialog page can use a server side branch to another dialog page. This has special semantics where the branch page replaces the current modal page inside the iframe. I'll explain how this works and why it is allowed.

    What a submit + branch (redirect) means and how it works:

    The browser is going to unload the current page, posting the form data to the server and receive a response that contains in the location header the url of a new page to load. (The browser makes two requests first post then get new page.) The urls to open a modal dialog are actually javascript code to run. In a link this works because the url uses the javascript: scheme so the browser executes the code. In a button the url is set as the onclick attribute which works because the javascript: is treated as a label and ignored. But a browser (the http protocol) doesn't allow the javascript scheme in the location header and that is why you get an error from the browser if you try. (Yes the error is cryptic but we have no control over the text - it is a browser message. But as you say we should implement branch validation so that it can't happen.)

    Now in 5.1 we changed how pages are submitted to support interactive grids but we tried to keep the semantics of submit + branch (redirect) the same. The intent is to be able to get validation error information in the response without the current page having been unloaded first. But in the case where there is no error we redirect to the new url. This works by using ajax to "submit" the page and then either displaying error information or redirecting to the url returned in the ajax response. This new way does not do a normal form submit and the response does not use the location header.

    It doesn't make logical sense to branch to a modal dialog in submit + branch. Because opening a modal dialog page assumes there is a current page to popup over (insert an iframe into the DOM and make it a modal pop over) but submit + branch means to unload the current page and replace it with the new one. For this to make any sense you would either need to specify, as part of the branch, the new page to load and the modal page to open as soon as the new page is loaded or assume that the current page is going to remain current and open the dialog. Both these things are completely different from what submit + branch means.

    So why is it OK for a modal dialog page to branch to another modal dialog page and how does this work:

    The wizard pattern is very common and needs to be supported. The term we use is chained dialog. Each dialog page that is part of the wizard reuses the same dialog. In this case it is the iframe page that is being replaced not the main page so the logical inconsistency mentioned above doesn't exist; there will be a page to popup over. It works because there is a special case in the response returned from the modal dialog page submit. Because the page is in an iframe in a dialog it must return some code to execute after the submit. The code either closes the dialog or replaces the iframe with the next page. You can see this by inspecting the response to the POST request. It contains the code to execute such as:

    <script type="text/javascript">

    <!--

    apex.navigation.dialog.close(true,function(pDialog){ apex.navigation.dialog("f?p=42083:9:...",{title:"Confirmation",height:"480",width:"720",maxWidth:"960",modal:true,dialog:pDialog},"t-Dialog--wizard",this); });

    //-->

    </script>

    If the response did not contain this code the dialog would never close.

    I hope this clears up any confusion.

    Regards,

    -John

    Toufiq - Hexagon PPM
  • Pavel_p
    Pavel_p Member Posts: 2,311 Gold Trophy
    edited Aug 4, 2017 9:30AM

    Hi John,

    thank you very much for the detailed explanation, however it will take a while to fully digest what you wrote.

    Have a nice day,

    Pavel

This discussion has been closed.