Condition Type – Request Is Contained within Expression

I've just remembered the issue that I've had few months ago with unexpected (at least for me) behavior of condition type Request Is Contained within Expression. A real headache to debug and figure out.

At first glance, when I saw this condition type, I’ve expected that requests must be in Expression 1, comma delimited, and that there must be an exact match on condition evaluation. But that’s not the case.

For example, if you have three buttons with requests CREATE, CREATE_ANOTHER and CREATE_AND_RETURN, and process condition with condition type Request Is Contained within Expression where Expression 1 equals CREATE_ANOTHER,CREATE_AND_RETURN:

the process will be executed no matter which button you press, even the one with request CREATE, because condition is evaluated as true when request string is contained within Expression 1 (without exact match).

So to avoid such behavior I always use condition type PL/SQL Expression with condition “:REQUEST in (...)”, for example:

Crazy little thing called dialog...

..today cost me a lot of nerves. I had a simple form and after every page submit, session state value of items were sequentially shifted (after page submit, value of first item become value of second item, value of second item become value of third item and so on...).

Initial form state

Form state after first submit

Form state after third submit

The first time after many years working with APEX I’ve got really pissed off. I’ve tried to isolate the problem, so I’ve deleted most of page items and had a form with only two items, with no processes, branches, dynamic actions...and it happened again – after submit, item values sequentially shifted. Then I’ve tried to create new page and all worked fine.

No matter what, I wanted to discover what’s the problem on the old page. After some time I got to POST request and found a clue. The items were submitted, but the sequence wasn’t right. I’ve got items posted in order from p_t02 to p_t03 and the p_t01 was missing. So I’ve opened FireBug and found it just before </BODY> HTML tag in jQuery UI Dialog. And the answer was here!

POST request

On page 0 there was a region (with “missing” item – p_t01) used for jQuery Dialog. After initialization of jQuery dialog, dialogs HTML was generated just before </BODY> HTML tag and the dialog region was pulled from its original position (inside <form id=” wwvFlowForm “> HTML tag) and moved just before the end of HTML body. As you may guess, only items inside <FORM> element are submitted to session state.

Quick solution of this problem was to put regions used for jQuery dialogs as last regions on page, so its items will get the last p_tXX values for name HTML attribute.

You can find test example here.

I hope that this post will help someone someday! :)

Edit on July 29, 2015:
More about this problem and order of submited items you can find here. 

View data from APEX collections in PL/SQL IDE

If you ever wondered, there's an easy way to see data from APEX collections in your favorite PL/SQL IDE (PL/SQL Developer, TOAD, SQL Developer...).

You only have to run short anonymous PL/SQL block and define:

• workspace name (workspace ID)
• application ID
• session ID.

Here's the script:

declare

  v_workspace_id apex_workspaces.workspace_id%type;

begin

  select workspace_id

    into v_workspace_id

    from apex_workspaces

   where workspace = '&WORKSPACE_NAME';

   

   -- Set Workspace ID

   apex_util.set_security_group_id(v_workspace_id);

   -- Set Application ID

   apex_application.g_flow_id  := &APP_ID;     

   

   -- Set Session ID

   apex_application.g_instance := &APP_SESSION;  

end;

After you run this script you can easily do query from apex_collections view and you'll see the result.