It’s been pretty manic over the past couple of months and we’re finally getting some time back to dedicate to building our Ext framework, and whilst a little rusty I still can’t believe how quick it is to implement new functionality. I was recently tasked with the property grid and the first step has been to produce the region and report templates to produce a read only version of it (part 2 will focus on turning it into an updateable grid).

Again I can’t begin to re-emphasize the importance of using templates, as it means that we can easily swap in and out functionality without tying into a technology too tightly (i.e. our APEX Ext app could become an APEX jQuery app by simply changing a theme, but seriously is there anything better than Ext?? .

Ok so our Ext property grid needs to look like something like this:

var grid = new Ext.grid.PropertyGrid({
    title: 'Properties Grid',
    autoHeight: true,
    width: 300,
    renderTo: 'grid-ct',
    source: {
        "(name)": "My Object",
        "Created": new Date(Date.parse('10/15/2006')),
        "Available": false,
        "Version": .01,
        "Description": "A test object"
    }
});

So the first step was to create the region template and we simply defined our DIV holders to render the grid into as well as adding our javascript call to render the widget e.g.

<div id="gridButtons#REGION_ID#" style="display:none;">#CLOSE##PREVIOUS##NEXT##DELETE##EDIT##CHANGE##CREATE##CREATE2##EXPAND##COPY##HELP#</div>
<div id="propgrid#REGION_ID#" ></div>
<script type="text/javascript">
var tbar#REGION_ID# = Ext.app.cleanButtonJSON("gridButtons#REGION_ID#","#REGION_ID#");
Ext.app.ApexPropertyGrid('propgrid#REGION_ID#',ext#REGION_ID#,tbar#REGION_ID#,#BODY#);
</script>

In the above our Ext.app.ApexPropertyGrid function will create the property grid however the “source” config parameter value will be produced by our report template. The interesting to note in the above is our #BODY# substitution string is the actual APEX report data and this will be returned as a JSON object in the form of:

{
   "(name)": "My Object",
   "Created": new Date(Date.parse('10/15/2006')),
   // date type
   "Available": false,
   // boolean type
   "Version": .01,
   // decimal type
   "Description": "A test object"
}

The question you might be asking is how can we get an object in the form of key value pairs as it’s not possible with the report template? Well it is but not in an obvious way, but we have to do a little javascript trickery. What we actually build with the report template is a 2 dimensional array and pass it to a function which transforms it into a key/value collection. The secret is that we use eval to achieve this, sorry that’s about as much as I’m allowed to give away.

Make a mental note: you can do almost anything with APEX templates it just might take a few post processing steps if your not able to get it right with the actual template fields provided.

But it still doesn’t solve outputting the data in the correct javascript data type does it? As we may need to define dates, integers, floats, strings etc. So how would we transform our report data? Answer: in the query itself, we simply run a custom PLSQL function formatValue over it:

SELECT extjs_json_util.formatValue(parameter)     parameter
,      extjs_json_util.formatValue(value, 'true') value
FROM   extjs_widget_app_level

This produces the following:

PARAMETER            VALUE
-------------------- ------------------------------
"Date"               new Date("22/06/2009")
"autoHeight"         true
"autoWidth"          false
"autoWidth"          true
"border"             false
"collapsible"        true
"draggable"          true
"enableColLock"      false
"filter"             true
"floating"           false
"forceFit"           true
"frame"              false
"grouping"           true
"height"             400
"height"             700
"iconCls"            "icon-form"
"iconCls"            "icon-grid"
"loadMask"           true
"shadow"             false
"stripeRows"         true
"tabPosition"        "bottom"
"width"              700

Note: I do hate putting code into the queries as it would have to be removed in the future if were to change to something else, but at the same time I prefer to work in PLSQL as much as possible rather than javascript, reason being is that I have access to the Database and APEX data dictionaries which I may need to reference.

Since the property grid is built on top of a normal grid we by default get our JSON object in the page header (thanks to a PLSQL region on page zero) and we get to reuse our already defined options button which allows us to customize the look and feel, I’m really lazy so being able to reuse something is great!

So the end result is a write once template based approach that was produced in a few hours for use in unlimited applications by unlimited developers and a base source of less than 200 lines of custom javascript. It’s a maintenance dream!! So that you should give you some incentive that you can incorporate custom functionality quickly, and if you’re not able to then there’s probably a simpler easier way to do it!

The other point to note is that the more integration you do the more productive you become working out how to integrate more functionality it just snow balls, so keep at it if you’re going down that route, worst case is you’ll get a better understanding of how you can get APEX to work for you and not vice versa!

The next phase is building the functionality to save the data changes. Here’s an example screenshot from our dev environment.

And here’s what the page looks like in the APEX IDE: