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!
5 comments:
Hi Tony,
it's actually by intention to not expose every switch Interactive Reports had as a declarative option in Interactive Grid. The reason is that we noticed that most developers never changed those default settings, but having all those switches added a lot of clutter to the configuration pages of an IR.
Even worse, some IR features which have been added later had to be migrated by switching them off (to not change existing behavior of the app). But when a developer created a new IR, it's on by default. With the result that end users experienced a different feature set between IRs of an application if the developer didn't modifies all existing IR.
I would be curious to find out what kind of customizations do you want to perform on a regular base and what is the background off limiting the out-of-the-box functionality? Maybe some of them can be exposed as a declarative option in the future.
Regards
Patrick
Patrick.
I disagree with what you described as intentional. Let's go back to basics, APEX is a low code platform by design and forcing the developer to write JS to get the IGs to work while a switch could define the behavior is a contradiction to the low code principle. Especially for basic things like disable actions on the IG toolbar.
In my opinion a developer is the one who decides to rely on switches or code and it's his/her responsibility to compare or whatever.
In my opinion the Interactive or Classic reports are not cluttered and we know they can be customized if needed. This is what makes APEX so good, just click on options or write code and produce an function rich app! Not offering the declarative options only takes away from the platform cause it adds nothing to it.
I hope oracle APEX team reconsiders that statement/direction for the sake of keeping the low code platform as low code.
Best Regards
Gaspar
Thanks, Patrick and Gaspar, for your comments. I can imagine there are plenty of difficulties in exposing such settings declaratively, and perhaps not many developers have a need to customise IGs (though I'd be surprised if so). However I'm 100% with Gaspar that having to write what I'd call moderately complex Javascript to disabled unwanted actions and features of IGs just isn't in the spirit the APEX. And I speak as someone who sometimes happily writes moderately complex Javascript e.g. when building bespoke plug-in item types - I just don't think having to do so should be "the norm" for configuring a standard APEX component.
The sort of customisations I want to perform are quite simple and are generally to declutter the UI for users by removing redundant (for their requirements) features:
- remove the filter/search functionality while retaining the toolbar for e.g. Add Record, Save.
- remove the toolbar action list completely
- remove individual actions from the action list e.g. Chart
- add a button to the toolbar
Basically, the sort of things you can do declaratively with IRs!
Also, I may be quite wrong here, but isn't there a danger that the architecture underlying IGs may change in a future release and break all the config Javascript code we have added?
Also, Patrick, re your point about new features and upgrades: won't exactly the same still be true with IGs now? Either old grids will suddenly gain new features, or the upgrade process will have to add Javascript to the IG to suppress it (while taking into account that it may already have some Javascript...)
I am with Tony and Gaspar. It seems to me Oracle release IG too soon ... and decide to unplug tabular form too soon.
Given all the threads I had read about IG, I decide to not use it for now. I will wait for next major improvement of the IG then start to explore it further.
The launching of IR is a wow to me... the launching of IG is "not that bad ... but please improve it".
Thanks!
Kevin Zhang
Post a Comment