As previously stated we have said that we are integrating ExtJS with APEX, however we haven’t really said how we are going to do it. Our aim with the integration is to provide all the Ext functionality within APEX page/region/report/list templates whilst still using the APEX wizards to create the page components to benefit from the RAD approach APEX provides. The functionality should be easy to switch on or off by simply switching the theme/template with some minor application level config changes at the most.

We have looked at a number of grid examples on the internet for inspiration, here’s one on the Ext forum and another on Mark Lancaster’s sample app. While impressed we felt that they were not integrated that well, i.e. Ext grid pagination required application level processes, grid sorting was handled locally and not server side, the grid was created based on the APEX report HTML table output etc.

What we set out to do was ensure that a standard APEX report created by the wizard, settings in the “Report Attributes” tab could be modified for sorting, summing, breaks, export, column conditions, column authorizations, additional markup, css styles, highlighting etc. would be reflected in an Ext Grid by simply selecting a custom ExtJS report/grid template. Sound ambitious? It probably was, but it’s a good test to see how flexible APEX is with a little know how.

Which comes to the integration design, which is the sweet part and I’ll get to it shortly. First though, what people mostly overlook with APEX, “in my opinion” is truly the best part about the product, is that your application is just metadata. What does this mean? Well it means that everything you need to know about your page and what’s on it can be queried via SQL and at any point that the HTML page is rendering, e.g. “Before Header”, “Before Regions” etc..

So what is the point? Well we can create JSON objects via PLSQL with report meta data at page load time to feed to the ExtJS grid widget, or via AJAX post page loading if later required. We simply add the Ext required javascript to the report templates and reference these JSON objects. We then use #REGION_ID# template substitution strings to make the javascript unique to ensure that the page can handle unlimited number of reports/grids.

The end result is a write once use many times template which turns our APEX report into an ExtJS grid in a split second. Multiply that for an application with 400 reports and you’ll start to see the true benefits. We have delivered quality web 2.0 functionality (well ExtJS has) without compromising productivity! Here’s a view of a prototype in development…

Note: if you’re interested in finding out more drop us an email at apex-sig@e-dba.com.