I was working on a customer’s application yesterday, to give you some background it’s an application we built back in 2007 with a user base of 7,500+. Unfortunately we can’t change the design or improve the layout significantly as it will require re-training for the entire user base, something our customer has enforced on us. 

I was specifically working on some changes to the data entry form to turn it into a master/detail form. The form is an ugly one, I must say, as it’s comprised of a significant number of our own custom dynamic actions for hiding/showing fields, auto complete’s, cascading LOV’s etc. The issue is that our new detail section is a number of repeating regions (a number of actions that need to be assigned to people within the company), i.e. similar to a tabular form but managed purely using regions/items which we control via hide/show functionality . Here’s a screenshot for an example:

So the problem lies in the fact that they wanted an end user to add up to 5 actions, originally it was one (a maximum of 5 actions were enforced on us by APEX as we can’t have over 100 items on the page, something the customer is Ok with even when we agreed to support up to 15, remember to watch out for the 100 limit, I never knew this until now, and found out the hard way I couldn’t believe that the customer was cool with this).

So with these 5 actions the user can add and remove them (or from a development perspective hide/show them), the problem is that they are APEX regions and defined in a particular area in the DOM. So lets say we add three actions and remove the second one when it comes time to add this one back we can’t simply show it in its original location as the user is expecting it to be the last one shown in the form. So what we had to do was move the form region in the DOM. Here’s a screenshot of the regions in the APEX IDE:

Note: we name all the region items exactly the same for each of the action regions we simply use an incrementing number to identify them e.g. P2_ACTION_1, P2_ACTION_2 etc. so we can easily code the hiding/showing, setting session state, and processing them using a simple loop.

To move elements around in the DOM we simply used the following:

$x('ACTIONS_CONTAINER').appendChild($x('P2_ACTIONS_'+i+'_CONTAINER'));

 

What this did was ensure that our regions were reordered within our region container, simply a DIV wrapper around the actions (see the previous image for the visual view). We called this reorder javascript just before we show the region which all works perfectly fine until we submit the page and then the bizarreness begins! Session state gets all out of whack when we submit the page.

Basically the wrong items get updated in session state and this is purely due to us moving the regions around in the DOM as APEX is expecting them in a particular order and will update session state based on this order. See the following OTN forum post for a similar more descriptive analysis.

Anyway this is a serious issue for us as we have been and are planning to do more and more DOM manipulation with Ext JS. So I do hope that the APEX development team is going to look at a better way to maintain session state regardless of where items are positioned in the DOM as the use of jQuery is going to explode in APEX 4.0 and this issue will surely become more mainstream.

Anyway the simple fix was simply to reorder the regions back to their original sequence before submitting the page. i.e. we simply set our buttons to redirect to a URL and called a reorder script before calling doSubmit(‘BUTTON_REQUEST’);

function repostionActions() {
   for (var i = 1; i < 6; i++) {
      $x('ACTIONS_CONTAINER').appendChild($x('P2_ACTIONS_'+i+'_CONTAINER'));
   }
}

On this occasion I’d actually admit for the first time that I’m disappointed with APEX as this is not a great design for managing session state (its also potentially unsafe and prone to data corruption if you start to think about scripting attacks)!