APEX Interactive Grids - what I've learned so far

My latest project has been building new pages on APEX 5.1, and quite a few of them have involved the new Interactive Grids (IGs).  I've learned I few things about them in the process, which I thought I'd record here both for my own benefit and in case it helps others.

They are addictive

I've seen a video of a David Peake presentation about IGs where he warns that developers will be tempted to overuse them.  It's true: once you've built a couple of IGs you are inclined to want to use them on every page instead of showing a report with an edit link.  They are very slick and modern in appearance.  But it's important to consider the users and whether the IG is the best interface for what they need to do.

They are very new

Like anything very new, they having teething troubles.  I've raised a number of issues on the Oracle APEX forum where things don't seem to work quite as they I would expect, or found issues that others have already raised.  These include:

• Issue with master-detail IG when master column is a select list (IGs are a lot happier with a hidden surrogate key or ROWID rather than a manipulable column as key)
• Item-type plugins are supported in IGs, but have quirks and don't work the same as when used in a page item e.g. p_param.value is always null.  Despite that I have managed to get one working, using a fair bit of Javascript and AJAX.
• IG scroll-type pagination doesn't work in modal pages - you just get the first 40 rows returned.
• Editable IGs are too wide by default with columns scrolling off to the right.

A common thread here is that these questions often don't get answered.  I think this is because there is only one person who might know the answer, and he is no doubt a very busy man!

Being new they are also somewhat scant on documentation.

They are complex to configure

Out of the box you can configure a few properties of an IG via the APEX Builder such as:

• Grid is editable or not
• Insert/Update/Delete operations allowed or not
• Toolbar is shown or not
• Save and Reset buttons are shown or not
• ... and several other things

However, they are nowhere near as declaratively configurable as Interactive Reports, which allows you to switch off individual features of the Toolbar its Actions list via property settings.  If you want to remove unwanted actions from an IG's toolbar (other than Save and Reset)  then you have to write some moderately complex Javascript that requires a knowledge of the IG's underlying architecture.  This is currently undocumented, but luckily John Snyders (who built them) has written a great series of blog posts about how to hack IGs that is indispensable if you need to make such changes.  I also found this blog post by SLino invaluable when wanting to drastically simplify an IGs config, and Explorer's review of IGs is a great way to get an overview of what is involved in developing with them.

I think that this complexity of configuration rather goes against the APEX principle of "low code", and very much hope that a lot more declarative control will be added in future versions of APEX.  But I appreciate that's a pretty tall order and Rome wasn't built in a day!

They can be slow to load

It seems that a lot of work goes on in Javascript when you load a page that has one or more IGs. On a modern browser like Chrome this isn't very noticeable and the page will be ready to use within a second or so even with a few IGs.  But IE11 (which is still the official browser for my users :-( ) takes about 5 seconds per IG, so a page with master-detail-detail IGs might take 15 seconds to initialise after page load.  I have heard that there will be some performance improvements in APEX 5.1.3, so look forward to seeing that.

Conclusions (TL;DR)

Interactive Grids are a great and powerful addition to the APEX toolkit, a vast improvement over the old tabular forms.  They should be used where they really add value, and not overused.  Being very new, they have a few issues, are not well-documented (compared to the rest of APEX), and require some quite advanced coding (and a lot of Googling) to configure if the default behaviour is not what you need.  I'm sure that by the time APEX 6.0 comes out they will be even better, and much easier to configure!

APEX applications that run without Javascript just got harder

Long ago in 2009 I wrote a blog post called Accessible APEX and in it there is a link to an application on apex.oracle.com that would work even when Javascript was disabled in the browser.  However, since APEX 5.1 changes the way page items are mapped, that old application no longer works when Javascript is disabled.

Oh dear , never mind, who cares?  Why would anyone in 2017 want to disabled Javascript in their browser?  Why should we care if they do?  And the APEX 4.2 Installation Guide states that: 

To run or develop Oracle Application Express applications, Web browsers must have JavaScript enabled.

(I can't find the equivalent statement for APEX 5.1 but it clearly still stands.)

Well, we have to build our applications for our customers, and believe it or not some customers even in 2017 insist that the application must work when Javascript is disabled.  For example, the UK's Government Digital Services (GDS), which controls any work built for UK government public-facing websites:

Make any new web page or feature usable from the start with only HTML - no images, CSS or JavaScript, just HTML.

...

Of course, some users turn off features in their browsers deliberately - you should respect their decision and make sure they can still use your service.

(In fact, GDS's rules preclude building in APEX for other reasons, such as it not being Open Source, but there is currently one GDS service running on APEX 4.2.5 and it works when Javascript is disabled!)

Prior to APEX 5.1 this wasn't too difficult to achieve: mainly it was a case of using a basic HTML submit button on forms rather than the default APEX buttons that use Javascript.  There was more to it than that to achieve a useful application, but that was the main difference.  When the page was submitted all the page items would still be passed to wwv_flow.accept via the p_vnn parameters.  But in APEX 5.1 these parameters are gone and all the page items and values are passed as a single JSON string - which is put together by APEX using Javascript.  If you disable Javascript, the JSON string is not generated and the page item values do not get updated in session state.

This is almost the final nail in the coffin of Javascript-disabled APEX applications - but not quite: you can still have Javascript-disabled APEX applications as long as you don't use page items!  The g_f01-g_f50 arrays used by legacy tabular forms (for example) still work, so you can use the apex_item package or your own equivalent to render HTML controls named "f01"-"f50" that get submitted via wwv_flow.accept whether Javascript is enabled or disabled.  To prove it I have created a new APEX 5.1 version of my 2009 application that works when Javascript is disabled.

It's not pretty, but it works...

If building a brand new application that had to run with Javascript disabled, APEX is probably not the ideal choice.  But at least it can be done if you really have to, and there is some kind of (difficult) upgrade path for pre-APEX 5.1 applications that are required to run with Javascript disabled.