We’re all eagerly awaiting APEX 4.0 and the new functionality, i.e. including tabular form validations. However some of us just can’t wait to see what we are going to get, so we end up doing/writing our own version first, which will probably be superseded and a total waste of time but that’s what we as developers do!
In our integration framework we found it very easy to enable the functionality in the tabular form since we’d already worked out the column mapping of DOM id’s/names for the tabular form input elements to their corresponding column (see our previous tabular form post), all we needed to do was put some additional information in our JSON meta data object in the page header to reference in our javascript transform routine which converts the normal input items e.g. select lists, date pickers etc into our ext equivalent ones.
To recap from previous posts, we create a tabular form using the APEX IDE and simply change the region & report template to our Ext custom templates which we have created. The templates render the APEX tabular form in an Ext grid. Each time the grid (re)loads we fire off an onload event which takes the DIV container ID of our Ext grid and uses an Ext.select to grab all the input items within it to transform into Ext equivalents. This transform function uses metadata in the page header to work out what transform to perform, i.e. Date, Textfield, Select List, Popup LOV etc. it also uses this meta information to set a number of Ext config parameters for the widget. This means we can easily set a vtype config parameter and enable a dynamic validation.
So our JSON meta data object in the page header contains the following fragment, which pulls the required vtype from the comments section of our tabular form column looking for the following syntax: $vtype:[validation] e.g. $vtype:email$
"vtypes" :
{ "f03" : "email" }
And our transform function just does the following (this is an example for a textfield):
try {
var lvType = eval("pMetaObj.vtypes." + el.dom.name);
} catch(e) {
var lvType = null;
}
var tf = new Ext.form.TextField({
"id": el.dom.id,
"vtype": lvType,
"allowBlank": lAllowBlank,
"applyTo": el.dom.id
});
tf.render();
The end result then looks like this:
In summary we think we’re on the right track with our framework design approach, simply because it doesn’t take us very long to implement new functionality, and its easy to maintain and update since it uses a single source and write once approach. We’d recommend a similar design if you’re looking to replicate the functionality or develop improved solutions. In essence its really just replicating the design of APEX client side, store everything in metadata and build everything on the fly through reusable api’s. i.e. store your meta data in JSON and reference it in your javascript when you build or transform page components… simple and a recipe for success because that’s what APEX is!
