[Update 5.1.1 28-Mar-2017] This article has been updated to reflect patch release 5.1.1
It is nice to see from the questions rolling in on the APEX forums that people are trying to do interesting and advanced things with Interactive Grid (IG). I’m happy to answer questions about how to do things programmatically with IG but in this
[Update 5.1.1 30-Mar-2017] This article has been updated to reflect patch release 5.1.1
[This article is about a beta release of APEX 5.1 known as Early Adopter 1 so the details are subject to change]
[UPDATE Jan-2017 APEX 5.1 was released. Don’t use the Early Adopter link. You can now try it out at apex.oracle.com. I made a few updates to this article as marked]
One of the major and eagerly awaited features of APEX 5.1 is Interactive Grid; an editable data table supporting master-detail and much more. You can learn about Interactive Grid by signing up for a workspace at the Early Adopter site, installing the Sample Interactive Grids application, running it and trying out each example. Be sure to read the overview section of each page. I expect in the coming weeks there will be tutorials and other information from a number of people about the features of Interactive Grid and how to use it in various ways. But here I want to talk about its internal architecture.
Why is it important to know about the internal architecture of Interactive Grid? Its not. To use a car analogy most people don’t care to know how their car works. What matters is that it gets them from point A to point B and possibly looks good as well. But some people like to know a little about how the car works, what’s under the hood, even if they never intend to service or build a car themselves. This article is for those who like to know how things work, and I expect there are a fair number of them in the APEX development community.
It has been a while since I have worked on the APEX Survey Builder packaged application but I still get questions about it. One question that comes up repeatedly is how to associate the questionnaire responses with the person that responded. At first this question surprised me somewhat because survey research is about populations not individuals so surveys should be anonymous. To quote Designing an Effective Survey by Mark Kasunic:
“A survey, when conducted properly, allows you to generalize about the beliefs and opinions of many people by studying a subset of them”
Survey research lets you say with confidence “87% of our customers feel that the produce makes them more productive” not that John Snyders thinks he is more productive after using the product.
In his 3 part series ending with APEX and the Order Items are Submitted, Martin D’Souza did a great job explaining how APEX page items are submitted and why you can’t reorder the DOM in arbitrary ways. If you haven’t read it already it I strongly recommend that you do so. I can’t improve on how he explained it but I have just two things to add.
Why does APEX do this?
I was very confused by this when I first joined the APEX team. I think that others especially people with front end web development experience will also wonder why APEX uses
p_tnn names rather than the more traditional way where you get to name your inputs as you please. For example
Martin explains that the
p_arg_names values are used to map the post parameter values back to the APEX item metadata. The other part of the puzzle has to do with how HTTP post parameters are passed into the APEX engine. The interface between the web listener and APEX Engine maps post parameters to PL/SQL procedure formal parameter names. So there is actually a PL/SQL procedure with formal parameters named
p_t02…p_t200. The same procedure is used for all apps and all pages so this is why fixed names must be used.
A subtle and unfortunate consequence.
If you have used any APEX applications you have undoubtedly run into the situation shown in the following image where the browser auto complete feature offers suggestions that have nothing to do with the current field.
How a browser implements the auto complete feature is up to the browser (meaning there is no common specification that must be followed) but the primary method of choosing what values to show is the name attribute. Fields with the same name tend to show the same auto complete choices. The underlying assumption that browsers are making is that web developers choose meaningful names for input fields such as
phone_number, etc. With APEX this assumption fails. Because the name attribute is assigned automatically and sequentially, it is the order of the form item on the page that determines what auto complete values will be shown.
I’m a little surprised that more people haven’t complained about this. Its a tricky problem to solve and it may not even be worth solving. How bothersome do you find this?