Databases Reference
In-Depth Information
Application performance will go down. APEX will call the apex item package for
each row and each column displayed on your page. (It will be even worse if you
build Tabular Forms manually since this will happen not only for displayed rows
but for the whole result set.) The time required to render a page after an update
process will increase dramatically.
The quality of data will suffer. Users will lose the “big picture” of their data and
will eventually need to remember their changes rather than see them, since they
need to scroll the screen in all directions.
The safety of data will be poor. It is quite easy to accidentally delete records
without even noticing it.
Tabular Forms Are Not Spreadsheets
One of the most frequent misunderstandings about Tabular Forms is that you can use them as a
replacement for Excel spreadsheets. At least one-third of the questions posted in the Oracle APEX forum
related to Tabular Forms concern this issue. The fact is, to a certain extent you can modify Tabular
Forms in order to simulate the behaviour of an Excel spreadsheet. You can add some JavaScript and
AJAX to it and make it behave like an Excel grid. However, very soon you will realize that there are many
limitations to this solution and that your code is exponentialy growing for every functionality you add.
What you definitely do not want is to have to support and debug that code later. Tabular Forms are not
meant to replace Excel—they have a completely different purpose.
New Features in APEX 4
As mentioned earlier, the first set of major changes to Tabular Forms happened in release 4 of APEX.
Some very important features were added and enhanced. We will try to cover them all.
New Item Types
In prior releases of APEX, Tabular Forms were somewhat limited compared to the single row Forms. A
couple of important items were missing. Release 4 corrected that issue by introducing the following item
types:
Single Checkbox
jQuery Date Picker
Radio Group
Popup Key LOV
Single Checkbox
In some cases your Tabular Form will need to provide a column of type Checkbox to give your users a
possibility to “flag” a record. Usually it will be “Yes” or “Y” for an activated checkbox and “No” or “N” for
the not checked (empty) state. In earlier versions of APEX such a requirement would cause a lot of
coding just to create a workaround for a simple problem. The Checkbox item is different than the other
items in APEX—its value will not be submitted to the server for the empty state. This means that the
Search WWH ::




Custom Search