Model of how APEX handles data (values)?

Question

Reference {thread:id=2486655}
I'm trying to get a model of how APEX handles data (values). There are several places(?) that data (values) can exist. Or so it seems. I'm trying to understand how these work -- to put all the pieces together.
Question:
A) Where data can be?
1) In the database
2) In the session
3) Rendered -- and hence displayed on the screen, if a displayed value -- but not in the session
4) In perhaps(?) some working memory pool(?) but different from the page rendered values I see on the screen?
5) Other?
Why do I think this is relevant?
Question:
B) If there are rendered values and session values different from the rendered values, then when code executes, which of these values (rendered or session) is it executing against?
And maybe the answer is, "You don't understand what's going on." Yes, "Exactly!" Hence the question.
Best wishes,
Howard

Answer 1

Howard (DBA in Training) wrote:
I'm putting this together now. For example:
I set the value of a Page Item (say, :P2_DATA) to "BEFORE" in a Before Region process and change it to "AFTER" in an After Region Process. 'BEFORE' was displayed on the screen but 'AFTER' was in the session state. So I see that PL/SQL changes these values in the session state. But it doesn't "go back" to change the HTML after the region has been rendered -- hence we see BEFORE shown on the screen. (I'll have to think about what a Dynamic Action does.)
Also, if a page item has a default value, say 'DEFAULT' then that value doesn't get into the session state. At least, not with my current settings. Oh, that explains a lot of confusion!! I suppose there's a logical reason for this but who would expect default values to be differently from other PL/SQL operations on the item?
Questions:
1) So why does a default value not get put into the session state?Several reasons, among them:
*1. When/why is the value required?* Region items (and thus their source and default values) are rendered in region/item sequence order. The item's source/default value would therefore not be available in session state until it's rendering point. This is frequently later in page show processing than the value is actually required, such as the common use case of including a data value in the page or region title. Setting the value in a Before Header/Regions computation or process makes it available as required before the item is actually rendered.
*2. The rendered page might not be submitted.* Default values are typically set when a page will create a new row. Consider the situation where the user clicks a "Create" button and is presented with an order entry form containing several default values. They then decide they don't want to create a new order after all, and navigate away from the form page via some mechanism that uses a redirect rather than a submit (such as a default "Cancel" button). This means that no page submit processing is performed, and generally that no session state management is performed. If the default values were set in session state, the order entry page would contain the default values for the non-existent order despite the user never submitting it. This may have unwanted side-effects if these values are referenced elsewhere in the application, and therefore would require extra session state management to be built into the application.
*3. A rendered item might not be submitted with the page.* Per the HTML specification, the values of disabled controls unchecked checkboxes are not POSTed on page submit. Consider a situation where a checkbox item is set with several default values, but the application requires that the checkboxes be cleared and disabled by a dynamic action if the user chooses certain options from a select list. In this case, on page submission no values are submitted into session state for the checkbox item. If the defaults had been set in session state, then the application would be in an inconsistent state, with the user-selected option indicating that none of the checkboxes were checked, but with session state holding values showing that they were. This would require additional processing to ensure that the application's state was consistent before saving it to the database.¹
2 & 3 are particularly significant in basic wizard-generated applications. Doing things in this way, the wizard-generated DML and navigation "just works", without the need for additional session state management.
2) Is there a Page Item setting that causes the default value to be saved to the session state?No. Hopefully the explanations above provide sufficient reason to show why this is genearlly not desirable. On the rare occasions when it is required, set the session state value using a computation or process.
¹ There are other reasons—mainly security related—that make it good practice to perform such checks in more complex and internet-facing applications anyway.