One issue that I run into periodically–especially when working with dynamic actions–is that the value of a page item in session state doesn’t match its value in the browser (what I call the DOM state). The simplest way to think about it is to view every page item as part of a form. Logically, when the user is entering data into a form, the HTML page elements have values that are not stored in APEX session state until the form is submitted. This is true whether the user is typing values in, or if the values are being set by a Set Value dynamic action or the $s(…) javascript function. And it’s true regardless of whether or not the page is actually a data entry form.
The issue that I run into is generally when I’m working on a different sort of page–typically, a report or a dashboard–that happens to include page items and dynamic actions. As an example, consider a page with two report regions, where the first region includes links; when the user clicks on a link, we want to set a page item and refresh the second report with details about the clicked-on link. This is a fairly straight-forward scenario, and can provide the user with a lot of relevant information in a compact, usable fashion.
My standard approach to this is to define the link target as a call to $s(…), which sets the value of a hidden page item. Then a dynamic action, set to fire on change of the hidden item, triggers the refresh of the second report region. But it turns out, this isn’t enough–because the $s(…) call sets the DOM state, while the report’s SQL is referencing the session state of the item. So although the report refreshes, it doesn’t reflect the new value of the hidden page item.
The solution, of course, is to set the session state of the hidden page item with the value from the DOM state. My first approach to doing this was to change the dynamic action to use two steps, with the first step being a PL/SQL action that looked like this:
The trick, of course, is the Page Items to Submit field, which is only present on PL/SQL actions; the values from any page items listed here are copied from the DOM state into session state when this action fires. There’s nothing else going on here, hence the null; code body. This solution works, but it’s pretty cumbersome, and isn’t self-documenting–someone looking at the dynamic action who doesn’t understand the trick is likely to be very confused by this action that “does nothing”.
Luckily, there’s a better way. When you edit a report, whether classic or interactive, you’ll note that there’s a Page Items to Submit field there, too! And it turns out that the submission happens whenever the report is refreshed, so by specifying the hidden page item in the list for the report, the original dynamic action–that just refreshed the report region–does exactly what we need it to. Much cleaner.
So, in general: whenever you build a report that depends on page or application items, go ahead and include those in the Page Items to Submit field. That way, if you ever decide to refresh the report via dynamic action, you won’t run into this issue.
Bert Sheffer says
September 23, 2014 at 1:33 pmGood to see that I’m not the only one who struggles with how the DOM and Session State work from time to time.
Raphael Harsch says
October 8, 2014 at 5:10 amHi David
i am trying a simple thing but it wont work for some reason.
i just set one dynamic action condition to look for the value of an item.
When i set the value at the beginning to zero and the condition also it works fine, but when i change the value of the page item the dynamic action is still fired. i tried your way but it seems that my session state from the value is first changed when i reload it with F5.
I also tried to set the session state from my item with APEX_UTIL.SET_SESSION_STATE(‘P11_FREIGABE’,1);
and refreshed my region with a dynamic action but its still not working.
David says
October 8, 2014 at 11:42 amGuten Tag, Raphael. (Yes, I’m assuming you’re German, based on your page item name.) When I’m debugging item change dynamic actions, I often add an extra step that fires before anything else that simply fires a JavaScript alert with the value of the page item. This does two things: first, it allows me to confirm that the dynamic action is firing when it should be, and second, it makes sure that the value is being set to what I think it is.
And if you’re using the page items to submit, you shouldn’t need to call set_session_state directly.
Hope that helps!
Raphael Harsch says
October 9, 2014 at 9:23 amHello David.
Thank you for your quick response and you guessed right i am from Germany.
Your tip was very helpful cause so i could fix out what the real problem was.
It hasn’t to do with session state or something like that the answer is quite easy.
A dynamic action condition is evaluated on page rendering, so at the page load process is the decision made if the dynamic action ist active or not and so i couldnt use my dynamic action after the condition was false for the first time and i needed to look for another way to solve my problem.
Thank you
David says
October 9, 2014 at 11:05 amRaphael,
There are two conditions on dynamic actions. It sounds like you’re using the one in the Condition region of the edit page, where you specify the standard condition type (exists, etc.); you’re right that this one determines whether or not the dynamic action is added to the page when the page is loaded. Pretty much the only time I use this one is during development–I’ll sometimes set it to condition:never, or to only render when I’m the active user (so as to not break the page for other developers).
The other one is what I think you’re looking for. In the When region of the edit page, you should see a series of fields; for an item change event, these are Event/Selection Type/Item(s)/Condition (the visible fields change based on your selections). This condition field is much more limited, but it allows you to test the value of the changed field when the dynamic action fires. Note that this condition field tests the DOM state value of the page item, not the session state.
Hope that helps.
Julissa says
October 27, 2014 at 10:18 pmthanks a lot!! I’ve been struggling with this 4 a while..
Poornima Alexander says
December 5, 2014 at 2:40 amThis was really helpful. Thank you loads!
Shane says
February 24, 2015 at 12:07 pmIssue I found is not submitting but the return. I have a PL SQL dynamic action that adjusts items based a certain value being submitted. I need to be able to return that item to the page but I can’t seem to find a routine/function to do this. I know there is a page items to return, but the item I want to return could be one of 21 different items. Putting all those items into the ‘page items to return’ section really slows down the access. I would like to just return the one item.
David says
February 24, 2015 at 12:29 pmI’m not sure I fully understand your requirements, but it sounds like you ought to have a dynamic action step (Execute PL/SQL code) that sets the item you need, rather than using the “page items to return” field.
Geza Toth says
March 22, 2015 at 9:28 amIt was big help for me, thanks for it!!!
Sekhar says
January 4, 2017 at 3:51 amHi David,
I have created one LOV which depends on onchange value of select_list and for this LOV, calling function in package to return dynamic select query which is based on different conditions. Here the problem I am facing is i am seeing the results in select query whenever page is loaded first time and when I change the new value I am getting new same results as we got on page load. Its looks like LOV code is not compiling when the value is changed? do I need to refresh LOV? if yes how?
Thanks for your time.
Regards,
sekhar
Katherine says
February 5, 2019 at 4:27 pmHello Dave.
I am trying to pass one value from one page to another value using a dynamic action in Oracle Apex 5.0.
I have a ”Next” button and when I click on it I wan this value from P3_LOT_N to pass onto item P4_LOT_N on page 4.
How do I go about doing this?
Thank you so much in advance.